Issue with image-based FXL reader

[JayPanoz]

So, that’s a tough one.

Say you have a fixed-layout file which is made entirely of images because distributor X is imposing this constraint for all fixed-layout files—it’s sad, I know, but there’s nothing I can do.

According to the spec, it will be passed to the image-based FXL reader on iOS and Android.

Now, let’s say you add audio files and javascript (custom controls for instance) in this file. The markup for this is obviously bigger than the markup for the image.

Finally, sideload this file to the iOS and Android apps and… it will be passed to the image-based FXL reader too. No audio, no controls, just images.

As far as I can tell, that’s not a criteria currently listed so could you tell me whether it’s a bug or an expected behavior?

[bdugas]

Interesting scenario. My initial thought is that this is a bug and that we hadn't envisioned content formatted this way when we rolled out the FXL image-based reader. If you can send a sample we'll verify your results and have it logged.

[JayPanoz]

Thank you for this promptness!

I'll check with my client. If he doesn't allow me to send you a sample, I'll try to recreate a file similar in all respects but it'll take a little bit longer.

[bdugas]

Sounds good. Much appreciated.

[JayPanoz]

OK so… funny story, the sample for the bug report doesn't trigger the bug it is supposed to report, which means I'll have to check what makes it work now.

I'll need a little bit more of time (luckily I've got backups to compare files and I suspect either tabindex or some aria- attribute is making it work in the non-image-based reader).

[bdugas]

I had a look at your files and could replicate your experience. I'd say these are rendering as intended but we hadn't considered JavaScript and interactivity at the time the feature was introduced. As a workaround I tested adding sample text into your HTML and making it invisible in the CSS and it disable the image based reader thus enabling your javascript.

Would that work for your purposes?

Ex.

this is text

invisible {
visibility: hidden;
}

[JayPanoz]

Thanks for the follow-up.

As regards

I had a look at your files and could replicate your experience.

Do you mean both files are “sent” to the image-based FXL reader? Cos I don't have this issue with the one with “OK” in the filename. Actually, I tried to isolate the issue and my best guess was that the length of the added markup (for JS) somehow was the important factor there.

We've discussed adding text then making it invisible with my client as a workaround as soon as I discovered this but it might become an issue on the long term, as regards other platforms, especially his own app.

[bdugas]

Sorry, to clarify the first file triggered the image based reader and the "OK" file did not. Looking through the code I can't see anything that's obviously causing the behavior. I'll share this internally but can't guarantee we'll be able to pin down what's triggering the "normal" reader in the second file.

[JayPanoz]

OK sorry for the delayed response, I've just discussed this issue with my client and got extra info. Would it be possible to continue by email as it seems extra weird to me?

(It works OK when side loaded but, for some reason, there's an inexplicable bug happening during validation.)

[bdugas]

Sure, email us and we'll go from there.