Closed Bug 798224 Opened 12 years ago Closed 12 years ago

Tabs and titlebar become transparent when the window is restored from being minimized by using the Windows 7 taskbar preview

Categories

(Core :: Graphics, defect)

18 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox18 - ---
firefox19 - ---

People

(Reporter: rockachu2, Assigned: jpr)

References

Details

(Keywords: regression)

Attachments

(2 files)

Attached image clear.png
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20121004030525 Steps to reproduce: When selecting a tab with the windows 7 taskbar preview, the firefox window is restored from being minimized. Actual results: tabs and titlebar went transparent, but they still respond. When loading an image (lik eon imgur) directly, the effect reverses until that tab is closed. Expected results: tabs to stay as normal
Effect permanently resolved to expected right after clicking 'submit' for this bug.
Hardware: x86 → x86_64
Are you able to reproduce the issue with the latest Nightly?
It seems to be intermittent, and was occurring when another bug was supposed to crash the browser (latest nightly crashes when hovering over tab preview)
oop, just did it again. It happens if the browser is NOT minimized, and you click on the tab preview. If only one tab is open, the FF menu goes transparent. IF more, then all the tabs go transparent. nightly 10-06-12
on 10-7-12's nightly build (x64), the issue is different. (see 2nd attachment)
Attached image problem as of 10-7-12
ok. The above attachment is probably another bug?
Yes, your 2nd screenshot is a different issue (a regression in this build from today) and I'm able to reproduce it (I guess a bug has already be filled)
(In reply to Notlost from comment #7) > ok. The above attachment is probably another bug? Indeed, it's bug 798931.
confirmed on nightly 10-10-12
Augh. 10-9-12, sorry.
Confirming as I see this on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121011030552 too with the steps in comment 4. Maybe related to bug 798274 or bug 724940?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 18 Branch → Trunk
I cant reproduce this with/without a new profile any more. Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0
I see it just now with today's nightly: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121012030610
STR (for me, working 99% of times) Nightly x86 on Win 7 x64 1.Open few tabs. 2.minimize Nightly window to taskbar. 3.Leave Your system untouched for some about 5 minutes. 4.Use taskbar preview, hover some tab and click to restore Nightly window 4.Nightly looks like: https://bug798224.bugzilla.mozilla.org/attachment.cgi?id=668331
Component: Untriaged → Graphics
Product: Firefox → Core
Summary: transparent tabs → Tabs and titlebar become transparent when the window is restored from being minimized by using the Windows 7 taskbar preview
Version: Trunk → 18 Branch
I'm able to reproduce the issue, but only with HWA enabled. It's hard to find a regression range because I'm hitting bug 793175 each time I try a build from early October.
Keywords: qawanted
Given the STR in comment 16, JP - can we find an engineer to take a look JP? Loic suggests a regression window may be difficult to find for QA.
Assignee: nobody → jpr
This is now happening all the time here on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121026030606 and it's really annoying. FWIW unchecking "Show tab previews in the Windows taskbar" under "Nightly" > "Options" > "Tabs"[1] make the "glassified" tabs go away immediately. Let me know if there's anything I could collect to help pin point the problem. 1| https://support.mozilla.org/en-US/kb/tab-preferences-and-settings
Hmm, I don't know how for others but form me problem seems to be fixed, didn't see that since some about 3 days or so...
I haven't been able to reproduce this problem on a few machines where I tried. These machines had HWA, task previews, and Aero theme enabled, and I used the latest Aurora and Nightlies. I was however able to crash on Aurora from around 10/17 (see comment #17), but other than that no luck. Alex, are you able to reproduce this in Safe-Mode? Are there any lightweight themes loaded? Is Flash running on any of the tabs where this is happening?
By the way, the crash I saw in Aurora in early Aurora builds was bp-5bd71906-6478-45a1-83ae-196172121108 and the way I got it was by hovering through the strip of tab previews, back and forth.
I think the issue has been fixed a week ago in Nightly. On my side, I cannot reproduce it even if I was able in comment #17.
bug 805534 may be a dupe.
(In reply to Loic from comment #23) > I think the issue has been fixed a week ago in Nightly. On my side, I cannot > reproduce it even if I was able in comment #17. Can you please help us find the window it was fixed on nightly ?Considering this is still an issue on Aurora we could uplift something that may have fixed this. Could it be around Bug 800319 landed ? as that may have fixed bug 805534 which this bug may be a dup of .. :) Thanks in advance
(In reply to bhavana bajaj [:bajaj] from comment #25) > Can you please help us find the window it was fixed on nightly ?Considering > this is still an issue on Aurora we could uplift something that may have > fixed this. Could it be around Bug 800319 landed ? as that may have fixed > bug 805534 which this bug may be a dup of .. :) Thanks in advance The regression range I found: m-c bad=2012-10-26 good=2012-10-27 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5ecff3e46ed5&tochange=f9acc2e4d4e3 And indeed, bug 800319 is present in this changelog. So it could be the fix of this current bug.
And bug 805534 is clearly a dupe of this one.
(In reply to Loic from comment #26) > (In reply to bhavana bajaj [:bajaj] from comment #25) > > Can you please help us find the window it was fixed on nightly ?Considering > > this is still an issue on Aurora we could uplift something that may have > > fixed this. Could it be around Bug 800319 landed ? as that may have fixed > > bug 805534 which this bug may be a dup of .. :) Thanks in advance > > The regression range I found: > m-c > bad=2012-10-26 > good=2012-10-27 > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=5ecff3e46ed5&tochange=f9acc2e4d4e3 > > And indeed, bug 800319 is present in this changelog. So it could be the fix > of this current bug. Thanks Loic. I have requested uplift of Bug 800319 on aurora which would fix this on aurora as firefox18 is affected.
For the STR in comment 16 I could reproduce in 2012-10-04 Nightly Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20121004030525 didn't reproduce in latest Nightly Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 Build ID: 20121112030753 reproduce in latest Aurora Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20121112042014 I tried to find a regression range, but because of bug 793175, every Nightly from mozregression after 2012-09-21 crashed, so I could not wait those 5 minutes from STR in comment 16 in order to reproduce this bug. Is there any extra QA work I could do for this?
Virgil, you don't really need to wait for 5 min. Just follow the STR of the dupe: https://bugzilla.mozilla.org/show_bug.cgi?id=805534#c0 But I think you'll not be able to find the regression range because of bug 793175 that crashed Nightly.
(In reply to Virgil Dicu [:virgil] [QA] from comment #30) > For the STR in comment 16 I could > > reproduce in 2012-10-04 Nightly > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 > Build ID: 20121004030525 > > didn't reproduce in latest Nightly > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 > Build ID: 20121112030753 > > reproduce in latest Aurora > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 > Build ID: 20121112042014 > > I tried to find a regression range, but because of bug 793175, every Nightly > from mozregression after 2012-09-21 crashed, so I could not wait those 5 > minutes from STR in comment 16 in order to reproduce this bug. > > Is there any extra QA work I could do for this? Thanks for the testing Virgil. I have recently approved a patch from bug 800319 on aurora which should fix the issue you reproduced on Aurora. Will be helpful if you can confirm it was indeed fixed once the patch lands on aurora . Thank you !
I tested in latest Aurora Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20121114042011 I can confirm the fix. I've tried as before steps from comment 16 and the issue was no reproduced.
Closing the issue as works for me as uplifting of patch in Bug 800319 on aurora has fixed the issue on this bug.Please reopen if this issue happens again.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Looks like this is fixed for 18/19 because 800319 was landed for 18/19 as well.
Verified on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 Beta 1 Build ID: 20121121075611 and Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 Aurora Build ID: 20121125042013 Verified the fix for both Firefox 18.0 beta 1 and Firefox Aurora 19.0a2. Issue was not reproduced.
QA Contact: virgil.dicu
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: