[e10s] Ctrl+Tab thumbnails sometimes rendered as black

NEW
Unassigned

Status

()

defect
P3
normal
3 years ago
10 months ago

People

(Reporter: dao, Unassigned)

Tracking

(Blocks 1 bug, {regression})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s?, firefox51 wontfix, firefox52 fix-optional, firefox53 fix-optional, firefox54 fix-optional)

Details

Not sure what exactly is going on here, but I think we're probably triggering the snapshot update at the wrong time.

Also, I think this is a regression.
Component: General → Keyboard Navigation
Component: Keyboard Navigation → Tabbed Browser
STR:

0. enable "Ctrl+Tab cycles through tabs in recently used order" in a new profile
1. open a new tab
2. accel+click on the "Mozilla Developer Network" tile
3. press ctrl+tab and keep ctrl pressed while MDN is loading

-> the thumbnail updates a few times while the page is loading but the final image is all black

This only happens with e10s.
tracking-e10s: --- → ?
Summary: Ctrl+Tab thumbnails sometimes rendered as black → [e10s] Ctrl+Tab thumbnails sometimes rendered as black
I can reproduce this on Mac 10.11 with Nightly 51.0a1, 20160817030202.

When was this feature introduced?

I'll dig up a regression range.
Flags: needinfo?(twalker)
(In reply to Tracy Walker [:tracy] from comment #2)
> When was this feature introduced?

It's been around for a long time but behind a hidden pref: browser.ctrlTab.previews
Priority: -- → P3
Mark 51 as fix-optional by P3.
Any progress here, Tracy?
The regression range is nearly 2 years ago.  I wasn't able to use mozregression to track this down. mozregression wasn't fully respecting prefs set to make sure this is reproducible.  builds with mozregression were not displaying suggested site tiles. So a manual one day regression range was all I could dig up.

last good build: 20150122030202
first buggy build: 20150123030203

This is a polish bug. The black tile persist only for the duration of holding ctrl in step 3.  If you release ctrl and retrigger (ctrl+tab) the tab preview and the previously black thumbnail correctly contains a content preview.
Flags: needinfo?(twalker)
(In reply to Tracy Walker [:tracy] from comment #6)
> The regression range is nearly 2 years ago.  I wasn't able to use
> mozregression to track this down. mozregression wasn't fully respecting
> prefs set to make sure this is reproducible.  builds with mozregression were
> not displaying suggested site tiles. So a manual one day regression range
> was all I could dig up.
> 
> last good build: 20150122030202
> first buggy build: 20150123030203
> 
> This is a polish bug. The black tile persist only for the duration of
> holding ctrl in step 3.  If you release ctrl and retrigger (ctrl+tab) the
> tab preview and the previously black thumbnail correctly contains a content
> preview.

Based on that, maybe bug 1088203? Dão, does that help?
Flags: needinfo?(dao+bmo)
(Looking at https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2015-01-22&enddate=2015-01-23, fwiw, which might not be entirely accurate... revisions would be better than dates, but it's late - I can look again if comment 7 is a terrible guess and we need a more accurate pushlog to keep looking)
(In reply to :Gijs from comment #7)
> Based on that, maybe bug 1088203? Dão, does that help?

Quite possible. Bug 1088203 adds async messages, changing the timing around when exactly we'd take a screenshot and perhaps exposing a race condition. The underlying issue that we get a black thumbnail when taking the screenshot at the "wrong" time is likely older and not a bug in front-end code.
Flags: needinfo?(dao+bmo)
See Also: → 1427629
Duplicate of this bug: 1496381
You need to log in before you can comment on or make changes to this bug.