887792 - Image do not appear immediately after tab switching

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Ben Aiken]

Attachment: FF_Path Issue.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36

Steps to reproduce:

0. Extract attachment
1 [review]. Open ffTest.html
2. Swap tabs (mouse pointer should be positioned outside of the image region)
3. Wait for about 20-30 seconds
4. Swap back to tab with ffTest.html and observe image not loading displaying immediately


Actual results:

Image does not immediately redisplay but rather displays after a 200-300ms delay.


Expected results:

Image should redraw immediately.

Comment 1

[Ben Aiken]

Reproducing steps should be (sorry, auto attachment linking messed it up in the original post):

0. Extract attachment 768290 [details]
1. Open ffTest.html
2. Swap tabs (mouse pointer should be positioned outside of the image region)
3. Wait for about 20-30 seconds
4. Swap back to tab with ffTest.html and observe image not loading displaying immediately

Comment 2

[Timothy Nikkel (:tnikkel)]

I think you are just seeing the delay between when we start decoding the image and when we finish, the image is quite large (6000x6000) so it doesn't decode instantly. The other option is to block the tab switch (so we keep drawing the previous tab) for a while until the image is decoded, you don't get the image flashing into view, but you can't see the rest of the contents of the new tab until the image is finished decoding either. Is there a version of Firefox where you observed something different from either of these two options?

Comment 3

[Ben Aiken]

Thanks for that explanation Timothy. I was under the impression that the issue didn't occur in v18 of FF (18.0 from here: https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/18.0/mac/en-US/), but now realize that the latter scenario is what seems to be happening - tab switching doesn't actually occur until the image finishes drawing.

That being said, what was the reasoning behind the change? I can understand why showing the selected tab immediately has its benefits, but the flashing image is pretty distracting as well and to me, a bit more of a sore thumb. I'd be curious to know what drove this decision.

Thanks!

Comment 4

[Timothy Nikkel (:tnikkel)]

I think the general position that we have right now is that we don't want small images to flash into view when switching tabs but we are okay with larger ones flashing into view. The reasoning behind this is that small images tend to form structural parts of pages (ui elements, buttons, and other things) where their absence is more visually jarring, and the flashing even more so. Larger images are usually photos and most people seem to have an in built reaction to expect them to have some short amount of loading time before they can appear. The lag between selecting another tab to view and actually having that tab be visible is something that we measure too, and it has been noted that it can be a particularly sore point on some lower end systems.

We also have a timeout for how long we will keep around decoded images in background tabs (as you noticed with the need for the 20-30 seconds pause), and this is a balancing act between memory usage and responsiveness.

What we have implemented in the code has changed over the months as we've tried to improve the situation and strike a better balance. And our current behaviour isn't an end point either, we have more ideas and forthcoming changes to try to make it better.

So basically it's a balancing act between user perceptions, expectations, memory usage, and responsiveness and we are open to suggestions for how we can improve the situation.

Comment 5

[Ben Aiken]

Completely understood and definitely appreciate the explanation. 

Do you have any specifics regarding the upcoming ideas/changes and any timelines associated with those?

Comment 6

[Timothy Nikkel (:tnikkel)]

This is just off the top of my head.

Bug 689623 means we will only try to decode images that are visible or nearly so when tab switching, it's turned on in 24 and up.

Bug 783748 is about something we'd like to do.

There were some changes to the behaviour in 22 and 23, but I don't have links handy. I mention this in case you were going to compare.

Comment 7

[Ben Aiken]

Okay definitely good information to know - much appreciated. I'll take this back to the team and see if anyone has other suggestions on how to potentially handle this better.

Comment 8

[Timothy Nikkel (:tnikkel)]

I'm not sure if it applies to your use case but the testcase doesn't seem to need such a large image. Using a smaller image would significantly mitigate or fix the issue.

Comment 9

[Ben Aiken]

Agree, and we have actually taken some steps on our side that unintentionally help mitigate this by having on-the-fly zoom-based image swaps which were done to help with bug 865546. However, we still use the 6000x6000 images for our highest-level zooms and need to for the added detail.

For context regarding the testcase provided - we allow users to pan in on a zoomed level of an image and while they might only be looking at a snapshot of the image, they can at any time choose to look elsewhere.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 17 votes.
:jwatt, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 11

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 12

[Robert Longson [:longsonr]]

If we decoded all images in non-visible tabs we'd use a lot more memory, and there's no guarantee that tab will ever become visible.