Closed Bug 1251868 Opened 8 years ago Closed 8 years ago

Screen Flash on Minimize

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
47 Branch
Platform:
All
Windows
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
firefox46 --- unaffected
firefox47 + verified
firefox48 + verified

People

(Reporter: jmjjeffery, Unassigned)

References

Details

(Keywords: regression, reproducible, Whiteboard: [gfx-noted] [fixed by patches from bug #1256084])

Attachments

(3 files)

bounce on close
988.30 KB, video/mp4
Details
Mozregression Logs.txt
2.40 KB, text/plain
Details
test.txt
1.38 KB, text/plain
Details 
I've noted that when you use the (minus) button on Windows, upper right of screen, that when you press to 'minimize' the screen will start to minimize, jump back up and then go down.

Regression window:
20160225025830 c1e0d1890cfee9d86c8d566b0490053f21e0afc6 ok
20160225142626 97cf677ee66802809808a3e61a0ccb89542ca54e bad

Cset's in range above:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c1e0d1890cfee9d86c8d566b0490053f21e0afc6%20&tochange=97cf677ee66802809808a3e61a0ccb89542ca54e

Nothing stands out as to possible cause.
Can you continue with the regression window search on inbound using mozregression?
(In reply to Jeff Muizelaar [:jrmuizel] from comment #1)
> Can you continue with the regression window search on inbound using
> mozregression?

I have not figured out how to use mozregression - hoping someone can, otherwise I have to do it the manual way, 1 download at a time/test - rinse and repeat.
Not seeing this on Windows 10 with Nightly. 

Try the latest release of mozregression-gui.exe. It's easier to use. https://github.com/mozilla/mozregression/releases
Sorry, not getting anywhere - will have to wait for someone I guess...
The issue is only occurring when you have e10s 'disabled'...

You also have to have a minimum of 4 tabs, preferably 5-6 + to see the problem, it does not manifest itself with only 1 or 2 tabs

When I get time later today, I'll try again with mozregression
Mozregression seems to have narrowed it down to:
https://bugzilla.mozilla.org/show_bug.cgi?id=1250333 

Not sure why as the builds it tested ALL failed with this issue of flash on minimize...
I don't really know how to break down results, it could also be pointing to bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1240799
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #7)
> I don't really know how to break down results, it could also be pointing to
> bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240799

here is the cset range from Mozregress:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3b913f81cb98b75061bb8c90f7780f88ac4b7dbb&tochange=3668019351bb2d8f819004b092ad62542b72cd57
for me the webpage flashes on maximize, it's very visible on dark webpages

[Tracking Requested - why for this release]: Regression
Severity: normal → major
Has Regression Range: --- → no
Has STR: --- → yes
status-firefox46: --- → unaffected
tracking-firefox47: --- → ?
Keywords: reproducible
Version: Trunk → 47 Branch
Two more runs with Mozregress and it twice now pointing to 
bug https://bugzilla.mozilla.org/show_bug.cgi?id=1249736
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #10)
> Two more runs with Mozregress and it twice now pointing to 
> bug https://bugzilla.mozilla.org/show_bug.cgi?id=1249736

This doesn't seem likely.
No matter how I try to bisect this issue with MozRegress I keep coming up bug:
1249736 at noted in comment 11

Anyone else able to repo this and confirm/or find the correct cset causing this ?
What are the exact STR to reproduce it?
(In reply to Loic from comment #13)
> What are the exact STR to reproduce it?

Sorry, STR in Comment #5
1. disable e10s
2. must have at least 4-5 or more tabs, I've been testing with 10 open to see the issue.
Is it possible to provide a screencast of the flash? I'm not able to see it (or I miss it).
Attached video bounce on close — 
Note it starts to close, clears the screen then 'bounces' up then goes down.
Still trying to tack this down.  Latest test run on m-i builds gives this push-log patch range:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8cb6123f31532d4c5d3da2a66716cdbcdac84979&tochange=406ee0a64991a8a9bc6b8ef9e1a27a16e80b9b15

Anything here look likely - it pointed to bug 1206346  but to me that seems unlikely.
Is it reproducible in safe mode and with a clean profile?
Whiteboard: [gfx-noted]
(In reply to Loic from comment #18)
> Is it reproducible in safe mode and with a clean profile?

Yes, New Profile, nothing added still produces...

STR:  Open 5-6 tabs, (note: blank tabs won't cause the issue, must have some form of content)
Open Options - > turn off e10s and re-start browser - not issue is present.

Still does not produce with e10s 'enabled'...
I've managed to reproduce this on the latest Nightly(47.0a1). For testing I've used Windows 7 x32. This only reproduces if e10s is disabled.

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160302030209

I've also performed a manual regression and the last good Nightly build was in 2016-02-25. This bug first appeared in Nightly on 2016-02-26.

Considering this, and the fact that the regression window was provided in previous comments, I will remove the "regressionwindow-wanted" keyword.
Keywords: regressionwindow-wanted
(In reply to Paul Pasca[:PoollyMcklayn] from comment #20)
> 
> Considering this, and the fact that the regression window was provided in
> previous comments, I will remove the "regressionwindow-wanted" keyword.

A Nightly window probably isn't small enough to be actionable. Is there any reason you didn't use mozregression to get an mozilla-inbound regression window?
Flags: needinfo?(paul.pasca)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #21)
> (In reply to Paul Pasca[:PoollyMcklayn] from comment #20)
> > 
> > Considering this, and the fact that the regression window was provided in
> > previous comments, I will remove the "regressionwindow-wanted" keyword.
> 
> A Nightly window probably isn't small enough to be actionable. Is there any
> reason you didn't use mozregression to get an mozilla-inbound regression
> window?

Did you see https://bugzilla.mozilla.org/show_bug.cgi?id=1251868#c17 ?  It was from m-i, but I didn't see anything in that range either that looked likely ?
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #22)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #21)
> > (In reply to Paul Pasca[:PoollyMcklayn] from comment #20)
> > > 
> > > Considering this, and the fact that the regression window was provided in
> > > previous comments, I will remove the "regressionwindow-wanted" keyword.
> > 
> > A Nightly window probably isn't small enough to be actionable. Is there any
> > reason you didn't use mozregression to get an mozilla-inbound regression
> > window?
> 
> Did you see https://bugzilla.mozilla.org/show_bug.cgi?id=1251868#c17 ?  It
> was from m-i, but I didn't see anything in that range either that looked
> likely ?

Yeah, nothing there seems terribly suspicious. Can you confirm a difference between build 8cb6123f31532d4c5d3da2a66716cdbcdac84979 and build 406ee0a64991a8a9bc6b8ef9e1a27a16e80b9b15?
(In reply to Jeff Muizelaar [:jrmuizel] from comment #23)
> (In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #22)
> > (In reply to Jeff Muizelaar [:jrmuizel] from comment #21)
> > > (In reply to Paul Pasca[:PoollyMcklayn] from comment #20)
> > > > 
> > > > Considering this, and the fact that the regression window was provided in
> > > > previous comments, I will remove the "regressionwindow-wanted" keyword.
> > > 
> > > A Nightly window probably isn't small enough to be actionable. Is there any
> > > reason you didn't use mozregression to get an mozilla-inbound regression
> > > window?
> > 
> > Did you see https://bugzilla.mozilla.org/show_bug.cgi?id=1251868#c17 ?  It
> > was from m-i, but I didn't see anything in that range either that looked
> > likely ?
> 
> Yeah, nothing there seems terribly suspicious. Can you confirm a difference
> between build 8cb6123f31532d4c5d3da2a66716cdbcdac84979 and build
> 406ee0a64991a8a9bc6b8ef9e1a27a16e80b9b15?

I just re-ran and again came up with same range.
Mozregress shows that 406ee fails, and 8cb612 passes

MozRegress is still pointing to bug: 1206346
Is it possible to back out that bug and build a 'try build' to test with ?
Hi Jeff,

I didn't use mozregression because other people had already provided a push log and the good and bad builds. So I checked the latest Nightly and I saw it still reproduces. And from previous comments I've found the last good build. It was more of a confirmation of what others did before me and that it still reproduces on the latest Nightly. We have a Nightly build every day, so if the last good build is 2016-02-25 and the first bad build is 2016-02-26, I think we've found the smallest window possible.

Thanks,
Paul.
Flags: needinfo?(paul.pasca)
Tracking this regression
tracking-firefox47: ? → +
(In reply to Paul Pasca[:PoollyMcklayn] from comment #26)
> Hi Jeff,
> 
> I didn't use mozregression because other people had already provided a push
> log and the good and bad builds. So I checked the latest Nightly and I saw
> it still reproduces. And from previous comments I've found the last good
> build. It was more of a confirmation of what others did before me and that
> it still reproduces on the latest Nightly. We have a Nightly build every
> day, so if the last good build is 2016-02-25 and the first bad build is
> 2016-02-26, I think we've found the smallest window possible.

Paul, we save "inbound" builds, which are smaller granularity than nightlies.  mozregression will in those cases return a smaller window than "good one day, bad the next", narrowing it down to a single check-in (e.g., comment 8.)

Setting regressionwindow-wanted again - we want to confirm the results from comment 8.
Keywords: regressionwindow-wanted
I've performed a regression, using Mozregression tool, and this are my results:

Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c1e0d1890cfee9d86c
8d566b0490053f21e0afc6&tochange=97cf677ee66802809808a3e61a0ccb89542ca54e

Last good revision: c1e0d1890cfee9d86c8d566b0490053f21e0afc6
First bad revision: 97cf677ee66802809808a3e61a0ccb89542ca54e

Is it safe to remove the "regressionwindow-wanted" keyword?
(In reply to Paul Pasca[:PoollyMcklayn] from comment #29)
> I've performed a regression, using Mozregression tool, and this are my
> results:
> 
> Pushlog:
> https://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=c1e0d1890cfee9d86c
> 8d566b0490053f21e0afc6&tochange=97cf677ee66802809808a3e61a0ccb89542ca54e
> 
> Last good revision: c1e0d1890cfee9d86c8d566b0490053f21e0afc6
> First bad revision: 97cf677ee66802809808a3e61a0ccb89542ca54e
> 
> Is it safe to remove the "regressionwindow-wanted" keyword?

This still looks like a mozilla-central regression window. Can you attach the mozregression logs? Perhaps there's a mozregression bug.
Attached file Mozregression Logs.txt — 
I've performed another regression and I've obtained the same results. The attachment contains a .txt file with the entire logs. The push log is the same as in my previous comment, but for some reason, Bugzilla made a link that contained only the first part of the push log. If you copy/paste the second row of the push log from comment 29, the push log is the same. Let me know if I can help further on this issue.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #30)
> (In reply to Paul Pasca[:PoollyMcklayn] from comment #29)
> > I've performed a regression, using Mozregression tool, and this are my
> > results:
> > 
> > Pushlog:
> > https://hg.mozilla.org/mozilla-central/
> > pushloghtml?fromchange=c1e0d1890cfee9d86c
> > 8d566b0490053f21e0afc6&tochange=97cf677ee66802809808a3e61a0ccb89542ca54e
> > 
> > Last good revision: c1e0d1890cfee9d86c8d566b0490053f21e0afc6
> > First bad revision: 97cf677ee66802809808a3e61a0ccb89542ca54e
> > 
> > Is it safe to remove the "regressionwindow-wanted" keyword?
> 
> This still looks like a mozilla-central regression window. Can you attach
> the mozregression logs? Perhaps there's a mozregression bug.


He merely found the same regression window I posted in comment #0 

Someone needs to try and verify my findings from comment #22 and following from the m-i regression I ran, twice, and came up with same regression range.  Granted the patches don't look suspicous, but unless someone can verify what I found, then we are still stuck as to the cause/regressor.
I filed bug 1254804 about mozregression not properly bisecting the inbound builds.
Depends on: 1254804
Can someone try improving the regression window starting with:

mozregression --good 9ecc9682c3a3 --bad 97cf677ee668 --repo inbound
No builds in that range passed, MozRegress came up with:

2016-03-09T07:22:49: INFO : Narrowed inbound regression window from [406ee0a6, 7ab8341b] (3 revisions) to [406ee0a6, 87a62c4c] (2 revisions) (~1 steps left)
2016-03-09T07:22:49: DEBUG : Starting merge handling...
2016-03-09T07:22:49: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=87a62c4c347446c5bf6bcdd1fa4808df3175463b&full=1
2016-03-09T07:22:50: DEBUG : Found commit message:
Bug 1237992 - service worker activate should be executed after install onstatechange events are fired. r=bkelly
Ben, heads up on bug 1237992.
Flags: needinfo?(bkelly)
It would be good if we could produce a patched nightly build with bug 1237992 backed out and have Jim test it.  Dimi, any chance of doing that?
Flags: needinfo?(dlee)
(In reply to Milan Sreckovic [:milan] (PTO until 3/23) from comment #37)
> It would be good if we could produce a patched nightly build with bug
> 1237992 backed out and have Jim test it.  Dimi, any chance of doing that?
Sure, I will provide it.
Is there anything even running a service worker in the tabs used to reproduce this?  I'd like to have some credible theory about why a service worker only change could affect widget behavior on win7, but not win10.  I can't reproduce on win10 with e10s disabled.

Right now I'm skeptical of this bisect result.
Flags: needinfo?(bkelly)
(In reply to Milan Sreckovic [:milan] (PTO until 3/23) from comment #37)
> It would be good if we could produce a patched nightly build with bug
> 1237992 backed out and have Jim test it.  Dimi, any chance of doing that?

build with bug 1237992 backed out
https://hg.mozilla.org/try/rev/3fe3fb0c94b8
Flags: needinfo?(dlee)
(In reply to Dimi Lee[:dimi][:dlee] from comment #40)
> (In reply to Milan Sreckovic [:milan] (PTO until 3/23) from comment #37)
> > It would be good if we could produce a patched nightly build with bug
> > 1237992 backed out and have Jim test it.  Dimi, any chance of doing that?
> 
> build with bug 1237992 backed out
> https://hg.mozilla.org/try/rev/3fe3fb0c94b8

Finally got home from work.  Sorry for delay.
I just tested this build and it DOES NOT fix the issue... so back to finding the regressor.  

thanks for the try, but I had doubts about this bug being the issue myself.

I'm still intrested in the bug I found in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1251868#c24

Possible to spin up a build with that patch backed out ?
FWIW, if this is intermittent in any way then mozregression won't be very reliable.

Should we get someone who knows the windows widget code to look?  This seems very OS specific to me.
(In reply to Ben Kelly [:bkelly] from comment #42)
> FWIW, if this is intermittent in any way then mozregression won't be very
> reliable.
> 
> Should we get someone who knows the windows widget code to look?  This seems
> very OS specific to me.

No, its 100% reproducible.  I suspect its very likely a Windows only bug, and could well be on Win7 x64, but I have no way to find that out, other than comments that folks on Win10 are not seeing it, or can't repo the issue.
Chiming in to say I'm seeing this in Windows 10 Pro 64-bit. 100% reproducible.
Attached file test.txt — 
(In reply to Jeff Muizelaar [:jrmuizel] from comment #34)
> Can someone try improving the regression window starting with:
> 
> mozregression --good 9ecc9682c3a3 --bad 97cf677ee668 --repo inbound

I've perform a regression using this range, but the first build is bad and mozregression throws a error(see entire log in the attachment). Also, this bug reproduces if you minimize the window by clicking on the Firefox icon on the start bar, just as if you click the minus(-) symbol on the top right next to maximize and close buttons.
Mozregress tool has been updated to use 'inbound' 
Ran the tool - but results are still to me inconclusive:

2016-03-20T05:10:16: INFO : platform_repository: https://hg.mozilla.org/integration/mozilla-inbound
2016-03-20T05:10:16: INFO : platform_version: 47.0a1
2016-03-20T05:11:23: INFO : Narrowed inbound regression window from [3b913f81, 36680193] (3 revisions) to [3b913f81, 2f43bc2f] (2 revisions) (~1 steps left)
2016-03-20T05:11:23: DEBUG : Starting merge handling...
2016-03-20T05:11:23: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=2f43bc2f7ffdec7157f47793397110f9e8651cdf&full=1
2016-03-20T05:11:24: DEBUG : Found commit message:
Bug 1250333 - do not create accessibles for trailing BRs, r=davidb, roc

2016-03-20T05:11:24: INFO : The bisection is done.
2016-03-20T05:11:24: INFO : Stopped

Its seemingly pointing to bug 1250333 do not create accessibles for trailing BRs

I am not using accessibility.
I should have noted above that 'none' of the tested builds loaded by Mozregress 'passed'
This appears to be Now WFM - 

Fixed by m-c merge cset:
https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=8a4359ad909f

Tried to run MozRegress to find the 'fix', but Mozregress is kicking error about not containing changelog/cset or something:

20160325190938 8a4359ad909fe0cffcfea512770483ffdf8cd4e6 Good
20160325190551 d4ccb3062261c79044eb88f7f63d3afd80740979 bad

The 'bad' cset is the build just before the 'good' one noted above. 

I'm not going to spend any more time trying to pin down the bug that resolved this issue.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
This seems to be fixed. Thanks Jim for all your work here. 
 
 Matheiu, since you were able to reproduce the issue, can you check to see if this is fixed for you in Nightly (or aurora, either one)?
status-firefox47: affected → fixed
status-firefox48: affected → fixed
tracking-firefox48: ? → +
Flags: needinfo?(mathieu.johnson)
Regression window (mozilla-inbound)
Good:
https://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1456381709/

Bad:
https://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1456386028/

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1f797f47e312c4ab9883bd48c9e3501619ff9e95&tochange=406ee0a64991a8a9bc6b8ef9e1a27a16e80b9b15

Caused by:
9ecc9682c3a3	Brendan Dahl — Bug 1104916 - Implement CSS media query display-mode. r=cam
Blocks: 1104916
Status: RESOLVED → VERIFIED
Has Regression Range: no → yes
status-firefox47: fixed → verified
status-firefox48: fixed → verified
Depends on: 1256084
Flags: needinfo?(mathieu.johnson)
Flags: needinfo?(bernesb)
Keywords: regressionwindow-wanted
OS: Windows 7 → Windows
Hardware: x86 → All
Resolution: WORKSFORME → FIXED
Whiteboard: [gfx-noted] → [gfx-noted] [fixed by patches from bug #1256084]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: