bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Images are not displayed or blank spaces left in Simplify page if they are not fully loaded on the website




10 months ago
10 months ago


(Reporter: ciprian_georgiu, Unassigned)



Firefox Tracking Flags

(firefox54 fix-optional, firefox55 fix-optional, firefox56 affected)



(4 attachments)

Created attachment 8871895 [details]
simplify page - issue images.png

[Affected versions]:
- latest Nightly 55.a01
- Beta 54.0b11

[Affected platforms]:
- Windows 10 x64
- Ubuntu 16.04 x64

[Steps to reproduce]:
1. Start Firefox
2. Go to: http://www.bbc.com/news/world-us-canada-40055458
3. Switch to Simplify page mode. (File -> Print Preview -> Simplify page)

[Expected result]:
- There are no blank spaces left in Simplify page and images are displayed properly
- or, if some of the images are not successfully loaded in website, the blank space for the picture in question is not displayed, only the text is displayed

[Actual result]:
- Image from the third page is not displayed in Simplify page and also, there's a blank space left

[Regression range]:
- This seems to be a regression as I cannot reproduce this issue on 50 Nightly (2016-06-06) where this feature first landed. However I'm not sure if this regression range is accurate, but here is the mozregression output:
Last good revision: a544ec8cb49864b7c8ff2921e47c9b64160ac1e7
First bad revision: 28e269b5ab120e15b7cf22f082befb1ed00cd5d5

Looks like the following bug has the changes which introduced the regression:

[Additional notes]:
- see the attached sceenshots
- This seems to be repro on bbc.com articles, although it might be other websites affected by this
- Please note, that this issue can be reproduced only if the web page from step 2 is not scrolled through the entire article (this way some of the images remains black or not fully loaded in the background and thus are not correctly displayed in Simplify Page). If the images are hovered or the web page is scrolled the issue cannot be reproduced anymore.

Comment 1

10 months ago
Created attachment 8871896 [details]
simplify page - compared.jpg
Created attachment 8872430 [details]
Preview/Simplify image placeholders - blank space
Created attachment 8872431 [details]
Preview/Simplify image placeholders - fully loaded images
I took a look at this one today and it seems that the disclosed issue already happens on print preview even if simplify page is not active. 

Print preview works like a cloned-document so _I guess_ if the print preview tab does not have all images loaded (only placeholders), the issue will also happen when simplifying since the content used is the one from the print preview tab.

Hey Mike, are you aware if we are lazily loading images for specific cases? Or if we already do that for every page?

Attachment 8872430 [details] shows  default preview output and simplify preview output side-by-side. Three images that were not fully loaded (webpage not scrolled down/images not hovered) did not get rendered when previewing.

Attachment 8872431 [details] shows default preview output and simplify preview output side-by-side after loading the aforementioned images.

URL used for testing: http://www.bbc.com/news/world-europe-40082346
Flags: needinfo?(mconley)
So, I was wondering if BBC's webpages listen to scroll events (or some sort) so it can execute some JS code after that. And it turns out that's the case. I've removed such event listeners for testing and images do not load on-demand (it remains as black boxes place-holding original images).

I think they do that to only load articles images on demand as users read the article?

It seems these image placeholders are taking up space in the DOM, and if original images are not in fact loaded, such DOM elements will occupy some space when print previewing.

What do you think, Mike? How do we deal with client scripts in this case?
(In reply to Matheus Longaray (:mlongaray) from comment #5)
> What do you think, Mike? How do we deal with client scripts in this case?

Good question. It doesn't look like either Safari or Chrome have great solutions for this either. Especially if images are being manipulated with script, I don't think there's a whole lot we can do here easily unless we want to build up a bunch of heuristics or something, and I doubt that it's worth it at this point.

While it's more a game of whack-a-mole, probably the better solution for this particular example is to have our WebCompat team reach out to the BBC and have them add CSS to display the images without any effects while printing (see [1]).

In general, I think this is out of scope for the Simplify Print work.

[1]: https://developer.mozilla.org/en-US/docs/Web/Guide/Printing
Flags: needinfo?(mconley)
status-firefox54: affected → fix-optional
status-firefox55: affected → fix-optional
status-firefox56: --- → affected
I actually don't think this is a regression. My guess is that you'll see the behaviour going back a long long ways - I suspect we've never properly handled images revealed / manipulated by script.
Keywords: regression
You need to log in before you can comment on or make changes to this bug.