Closed Bug 1195623 Opened 9 years ago Closed 9 years ago

Alt-Tab shows a small Nightly window with colorful blocks in it, which I can't actually alt-tab to, on first Firefox launch after win10 upgrade

Categories

(Core :: Graphics, defect)

Unspecified
Windows 10
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla43
Tracking Status
firefox43 --- fixed

People

(Reporter: dholbert, Assigned: dvander)

References

Details

(Whiteboard: gfx-noted)

Attachments

(3 files)

So, I just upgraded my home desktop to Windows 10. The first time I started Firefox Nightly in the new environment, I noticed that "alt-tab" showed a bonus Firefox window, which was small and had some colorful blocks in it. I couldn't actually see it, though -- it was only visible in the alt-tab switcher. It stuck around, too -- the window was present in my alt-tab switcher until I quit Nightly (after maybe 5-10 minutes). The next time I reopened Firefox, the window was no longer there in my alt-tab switcher. So this may be a "firstrun-only [after upgrade?]" sort of a bug. Still, it's a bit disconcerting. Mason, I suspect this might be the background "let's see how buggy your graphics driver" window that you've done some work on. Have you encountered this issue or heard of this happening?
Flags: needinfo?(mchang)
Yeah that looks like the sanity test. Interesting that it didn't close... If you create a new profile, can you reproduce this with any consistency? It should only run on new profiles / gpu upgrades. Also, can you report any values you see in about:telemetry with the histogram keys of GRAPHICS_SANITY_*?
Flags: needinfo?(mchang) → needinfo?(dholbert)
Whiteboard: gfx-noted
(In reply to Mason Chang [:mchang] from comment #2) > If you create a new profile, can you reproduce this with any consistency? It > should only run on new profiles / gpu upgrades. No. With a new profile, I see the window in alt-tab for a few seconds, and then it goes away. So now it seems to be working as-expected, I think. > Also, can you report any values you see in about:telemetry with the > histogram keys of GRAPHICS_SANITY_*? (Back to using my main profile now.) I don't see any GRAPHICS_SANITY_ values there. (Checked "Histograms" and "Keyed Histograms") The only graph I see with GRAPHICS is in the histogram section, and it's called GRAPHICS_DRIVER_STARTUP_TEST, and it shows a single sample at the value "0". (1 samples, average = 0, sum = 0) Not sure if that's related to this at all.
Flags: needinfo?(dholbert)
Attached file about:support "graphics" section (deleted) —
(here's the graphics section from "about:support", for completeness / in case it helps)
Flags: needinfo?(dvander)
OS: Unspecified → Windows 10
It looks like the timeout to close the window got nuked when we removed OS snapshotting. I'll add it back.
Assignee: nobody → dvander
Status: NEW → ASSIGNED
Flags: needinfo?(dvander)
Attached patch fix (deleted) — Splinter Review
Attachment #8649603 - Flags: review?(mchang)
Comment on attachment 8649603 [details] [diff] [review] fix Review of attachment 8649603 [details] [diff] [review]: ----------------------------------------------------------------- ::: toolkit/components/gfx/SanityTest.js @@ +19,5 @@ > const DEVICE_PREF="sanity-test.device-id"; > const VERSION_PREF="sanity-test.version"; > const DISABLE_VIDEO_PREF="media.hardware-video-decoding.failed"; > const RUNNING_PREF="sanity-test.running"; > +const TIMEOUT_SEC=6; Why these numbers? @@ +172,5 @@ > + setTimeout(TIMEOUT_SEC * 1000, () => { > + if (this.win) { > + reportResult(TEST_TIMEOUT); > + this.endTest(); > + } Just out of curiosity, do we have to do anything to cancel the win.onload from firing?
(In reply to Mason Chang [:mchang] from comment #7) > > const DEVICE_PREF="sanity-test.device-id"; > > const VERSION_PREF="sanity-test.version"; > > const DISABLE_VIDEO_PREF="media.hardware-video-decoding.failed"; > > const RUNNING_PREF="sanity-test.running"; > > +const TIMEOUT_SEC=6; > > Why these numbers? It's between 5 and 7! > @@ +172,5 @@ > > + setTimeout(TIMEOUT_SEC * 1000, () => { > > + if (this.win) { > > + reportResult(TEST_TIMEOUT); > > + this.endTest(); > > + } > > Just out of curiosity, do we have to do anything to cancel the win.onload > from firing? Hrm, good question. I'm not sure but I can find out.
(In reply to Mason Chang [:mchang] from comment #7) > @@ +172,5 @@ > > + setTimeout(TIMEOUT_SEC * 1000, () => { > > + if (this.win) { > > + reportResult(TEST_TIMEOUT); > > + this.endTest(); > > + } > > Just out of curiosity, do we have to do anything to cancel the win.onload > from firing? The answer looks like no.
Attachment #8649603 - Flags: review?(mchang) → review+
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: