Paul Reporter
	Description • 12 years ago

This is Nightly 19a 2010-10-16

Related to hardware acceleration. 

reproducible (did on two platforms). One laptop with i965 graphics and desktop with GTX 285. Both win7 64 bit and 64 bit nightly

1: Press Ctrl+D
2: click folder to bring the folder menu out
3: click any place within the "edit bookmark" that should bring the folder menu back up. it stays rendered. Sometimes after the entire edit bookmark is gone from a outside of edit bookmark click

with hardware acceleration disabled, it works fine

	Alice0775 White
	Comment 2 • 12 years ago

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/f972f1a71e7e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120830145943
Bad:
http://hg.mozilla.org/mozilla-central/rev/6873940886b2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120830185450
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f972f1a71e7e&tochange=6873940886b2



Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/5034469b1595
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120830091924
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/e0ceffe737dd
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120830094924
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5034469b1595&tochange=e0ceffe737dd

Regressed by:
e0ceffe737dd	Timothy Nikkel — Bug 786421. When hiding a popup panel don't bother sizing its view to zero because that is useless and confuses the widget sizing code. r=roc Panels have a min size constraint set on them so when the view code tried to resize the widget to zero it would get bumped up to the min size. The view code would continue trying to resize the widget because of this.

	bhavana bajaj [:bajaj]
	Comment 3 • 12 years ago

Tim, can you please take a look at this bug as it is a suspected regression from 786421. Thanks !

	Timothy Nikkel (:tnikkel) Assignee
	Comment 4 • 12 years ago

Bug 786421 caused this and it's on 17, so we might want to track there too.

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 5 • 12 years ago

Tim if you're able to put together a forward fix in the next week or so we could take it on 17, otherwise can you make a call here on whether this regression justifies a backout of bug 786421 or if it's something that shouldn't affect too many users and we can keep tracking for a fix in 18 to give you more time.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 6 • 12 years ago

I've tried to reproduce on my Windows 7 machine but I haven't been able to.

Maybe I'm not doing the steps right? Could someone right out even more detailed steps maybe?

Maybe it's because I have d3d9 layers and no d2d. Alice and Paul what kind of acceleration do you have? (about:support has the info).

	Alice0775 White
	Comment 7 • 12 years ago

Steps to Reproduce:
1. Start Firefox with New profile
2. Ctrl+D or Double-click Star UI
3. Click "x" to dismiss "You can access your bookmarks on all your devices with Sync.Lerm more" information pane(if exist),
4. Click "Recent used folder drop down arrow" at Folder row
5. Click page empty area

Actual results:
You can see garbage of "Recent used folder drop down"

Expected results:
"Recent used folder drop down" should be hidden.

Graphics
Adapter Description  ATI Radeon HD 4300/4500 Series
Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 512
ClearType Parameters: Gamma: 2200 Pixel Structure: RGB ClearType Level: 50 Enhanced Contrast: 50
Device ID: 0x954f
Direct2D Enabled: true
DirectWrite Enable: dtrue (6.1.7601.17789)
Driver Date: 7-3-2012
Driver Version: 8.970.100.3000
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 10
Vendor ID: 0x1002
WebGL Renderer: no information
AzureCanvasBackend: direct2d
AzureContentBackend: direct2d
AzureFallbackCanvasBackend: cairo

	Timothy Nikkel (:tnikkel) Assignee
	Comment 8 • 12 years ago

Thanks.

What happens if you disable d2d? Or use d3d9 layers?

And the "garbage", what happens if you scroll the page? How can you make it go away?

	Alice0775 White
	Comment 9 • 12 years ago

(In reply to Timothy Nikkel (:tn) from comment #8)
> Thanks.
> 
> What happens if you disable d2d? Or use d3d9 layers?
> 

Setting layers.prefer-d3d9 = true and restart: the problem also happens.
Disabled HWA from Oprions  and restart: the problem is gone.

> And the "garbage", what happens if you scroll the page? 

 "garbage"stays on the "Edit Bookmarks Panel".

> How can you make it go away?

Following step 5 and
6. Click page empty area  --- "Edit Bookmarks panel" will be hidden as expected
7. Scroll page  --- the "garbage" will be dismissed

	Alice0775 White
	Comment 10 • 12 years ago

You may need to change Window Visual Style to "Aero Basic" or "Classic" to reproduce the problem

	Timothy Nikkel (:tnikkel) Assignee
	Comment 11 • 12 years ago

Here are four try builds (to show up in a bit), could someone try them to see if they change anything?

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-ed2919fc72d9
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-a5b3e1cef487
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-02562f282827
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-05f950fc8677

	Timothy Nikkel (:tnikkel) Assignee
	Comment 12 • 12 years ago

(In reply to Alice0775 White from comment #10)
> You may need to change Window Visual Style to "Aero Basic" or "Classic" to
> reproduce the problem

Thank you for this. I can reproduce in Basic and Classic.

	Alice0775 White
	Comment 13 • 12 years ago

tnikkel@gmail.com-ed2919fc72d9  --- Nothing seems to have changed
tnikkel@gmail.com-a5b3e1cef487  --- Nothing seems to have changed
tnikkel@gmail.com-02562f282827  --- Nothing seems to have changed
tnikkel@gmail.com-05f950fc8677  --- Nothing seems to have changed

	Paul Reporter
	Comment 14 • 12 years ago

you are correct, both of the systems are on windows basic. it does not do it with areo enabled. good catch

	Timothy Nikkel (:tnikkel) Assignee
	Comment 15 • 12 years ago

Does it happen on Windows XP at all?

	Paul Reporter
	Comment 16 • 12 years ago

let me boot to my xp install on my laptop

nope. Only 7. If you ask about vista next, I can't answer that, I'm sane enough to keep that away from everything like a plague

	Timothy Nikkel (:tnikkel) Assignee
	Comment 17 • 12 years ago

The fact that this only occurs with a non-compositing window manager and hardware accelerated layers makes me thing this could be a Windows bug. We have a popup window on top of a popup window. Let's call the top most popup A, the popup below it B, and the main window C. When A is hidden the parts of A that are only over C correctly disappear, but the parts of A over B do not. The weird part is that when B is hidden the left over parts of A still visible remain on top of just C, and they go away if we invalidate the area of C normally.

	Jim Mathies [:jimm]
	Comment 18 • 12 years ago

Hmm, I would have hoped the fix for bug 610713 might have addressed this.

One interesting thing I noticed is that if you set focus to the tags edit and try typing, the text edit doesn't update at all. Seems like the top level Bookmarks panel view isn't refreshing after the drop down goes away. I wonder if we are invalidating the window there? If we do and Windows doesn't generate a corresponding paint, then it may be a Windows bug. If we aren't then it's our fault.

	Jim Mathies [:jimm]
	Comment 19 • 12 years ago

Looks like we are invalidating - 

  63 Invalidate widget=08004440 name=noname       id=00B706D0 rect=118,147   1,17
  64 Invalidate widget=08004440 name=noname       id=00B706D0 rect=118,147   1,17
  65 Invalidate widget=08004440 name=noname       id=00B706D0 rect=118,147   1,17

From the blinking cursor in the tags edit. 

One good note - this isn't reproducible on Win8.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 20 • 12 years ago

One more data point: not all computers show the problem when using a non-compositing window manager and accelerated layers. Dell laptop with ATI graphics has the problem. Old HP netbook with nvidia ion or intel graphics has the problem. Macbook with ATI graphics does not have the problem.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 22 • 12 years ago

(In reply to Jim Mathies [:jimm] from comment #18)
> Hmm, I would have hoped the fix for bug 610713 might have addressed this.

I realized that bug 610713 only affects menus. So I made a try build that applies that style to all popup windows. It will be ready in a bit at

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-9fddc0ff7f1e/

	Alice0775 White
	Comment 23 • 12 years ago

(In reply to Timothy Nikkel (:tn) from comment #22)
> (In reply to Jim Mathies [:jimm] from comment #18)
> > Hmm, I would have hoped the fix for bug 610713 might have addressed this.
> 
> I realized that bug 610713 only affects menus. So I made a try build that
> applies that style to all popup windows. It will be ready in a bit at
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-
> 9fddc0ff7f1e/

This tryserver build fixed this problem!

	Timothy Nikkel (:tnikkel) Assignee
	Comment 24 • 12 years ago

Perfect! Thanks for all your help Alice!

I'll put together a patch that we can land.

	Alice0775 White
	Comment 25 • 12 years ago

And the tryserver build also seems to fix Bug 785708.

	Paul Reporter
	Comment 26 • 12 years ago

yay I helped

and now have bragging rights to other techs

thanks for the fix, keep up the good work

	Timothy Nikkel (:tnikkel) Assignee
	Comment 27 • 12 years ago

We need to remove the condition on both the popup type and drop shadow being there.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 28 • 12 years ago

Comment on attachment 673522 [details] [diff] [review]
patch

Want to land this ASAP to get as much testing as possible done for a potential uplift to beta.

	Jim Mathies [:jimm]
	Comment 29 • 12 years ago

Comment on attachment 673522 [details] [diff] [review]
patch

I'm wondering if this might cause perf issues, I suppose there's one way to find out - land it on inbound and see what happens in talos tests like tresize.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 30 • 12 years ago

(In reply to Jim Mathies [:jimm] from comment #29)
> I'm wondering if this might cause perf issues, I suppose there's one way to
> find out - land it on inbound and see what happens in talos tests like
> tresize.

It still only affects popup windows (so menus, tooltips, panels). tresize just resizes the main window right? So I don't think it'll affect that. It could be a perf issue with panels though.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 31 • 12 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/30dd8e889317

	Timothy Nikkel (:tnikkel) Assignee
	Comment 32 • 12 years ago

We could also make this conditional on a non-compositing window manager being used, or maybe on accelerated layers being used too.

	James
	Comment 33 • 12 years ago

Just noting that the patch in 610713 only applied to menus and not all popup types because I was getting invisible tooltips. Bug 802316 seems to have fixed that though, so keep that in mind if you consider uplifting this to beta.

	Ryan VanderMeulen [:RyanVM]
	Comment 34 • 12 years ago

https://hg.mozilla.org/mozilla-central/rev/30dd8e889317

	Timothy Nikkel (:tnikkel) Assignee
	Comment 35 • 12 years ago

(In reply to James from comment #33)
> Just noting that the patch in 610713 only applied to menus and not all popup
> types because I was getting invisible tooltips. Bug 802316 seems to have
> fixed that though, so keep that in mind if you consider uplifting this to
> beta.

Yeah, I did see that bug and that was my plan, to uplift it as well. Thanks for the reminder.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 36 • 12 years ago

(In reply to Jim Mathies [:jimm] from comment #29)
> I'm wondering if this might cause perf issues, I suppose there's one way to
> find out - land it on inbound and see what happens in talos tests like
> tresize.

To determine the perf impact we could put an animation in a panel and measure fps or cpu in before after/builds.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 37 • 12 years ago

This is just this bug and bug 802316 combined.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 38 • 12 years ago

This is bug 610713, bug 802316, bug 801301, and this bug rolled up into one patch.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 39 • 12 years ago

Comment on attachment 674398 [details] [diff] [review]
rollup aurora patch

This is a rollup of this bug and bug 802316.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 786421
User impact if declined: people running Aero Basic will see buggy rendering in some secondary interactions with tooltips, panels, and menus
Testing completed (on m-c, etc.): been on nightly for a few days
Risk to taking this patch (and alternatives if risky): low risk
String or UUID changes made by this patch: none

	bhavana bajaj [:bajaj]
	Comment 40 • 12 years ago

Comment on attachment 674398 [details] [diff] [review]
rollup aurora patch

Approving for aurora at this time, please nominate for beta once it has had enough bake time as this is tracking 17

	Timothy Nikkel (:tnikkel) Assignee
	Comment 41 • 12 years ago

I landed the patch as two separate changesets to preserve author, review, and bug information.
https://hg.mozilla.org/releases/mozilla-aurora/rev/4af749bc6e82
https://hg.mozilla.org/releases/mozilla-aurora/rev/b100957a878e

	Timothy Nikkel (:tnikkel) Assignee
	Comment 42 • 12 years ago

Had to back out from aurora, as it looks like either this or bug 802316 caused an intermittent orange.
https://hg.mozilla.org/releases/mozilla-aurora/rev/fd8361463029

	Alex Keybl [:akeybl]
	Comment 43 • 12 years ago

(In reply to Timothy Nikkel (:tn) from comment #42)
> Had to back out from aurora, as it looks like either this or bug 802316
> caused an intermittent orange.
> https://hg.mozilla.org/releases/mozilla-aurora/rev/fd8361463029

Please target getting a fix for this all the way up to beta before Tuesday (b4 build), and email if help is needed investigating the intermittent orange. Thanks!

	Timothy Nikkel (:tnikkel) Assignee
	Comment 44 • 12 years ago

(In reply to Alex Keybl [:akeybl] from comment #43)
> Please target getting a fix for this all the way up to beta before Tuesday
> (b4 build), and email if help is needed investigating the intermittent
> orange. Thanks!

Ok.

Given that this only affects Aero Basic we may want to re-evaluate the risk-benefit ratio here.

	Alex Keybl [:akeybl]
	Comment 45 • 12 years ago

(In reply to Timothy Nikkel (:tn) from comment #44)
> (In reply to Alex Keybl [:akeybl] from comment #43)
> > Please target getting a fix for this all the way up to beta before Tuesday
> > (b4 build), and email if help is needed investigating the intermittent
> > orange. Thanks!
> 
> Ok.
> 
> Given that this only affects Aero Basic we may want to re-evaluate the
> risk-benefit ratio here.

Is the fix high risk, or the intermittent orange mysterious? Basically, why compromise here?

	Timothy Nikkel (:tnikkel) Assignee
	Comment 46 • 12 years ago

(In reply to Alex Keybl [:akeybl] from comment #45)
> Is the fix high risk, or the intermittent orange mysterious? Basically, why
> compromise here?

The orange is rather mysterious to me at this point.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 47 • 12 years ago

http://hg.mozilla.org/mozilla-central/rev/b486c3782846 is what "fixed" the intermittent failure, which is just a large change to the failing test. I'm a little stumped as the change in this bug should not have an effect on this test.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 48 • 12 years ago

This is an alternate patch.

It backs out the original regressing patch from bug 786421 and instead adjusts the size constraints of the widget to allow it to be zero sized when we are hiding it. This is an alternative fix for bug 786421, and it should be safer. Although it has had much less testing.

	Neil Deakin
	Comment 49 • 12 years ago

Comment on attachment 676251 [details] [diff] [review]
alternate aurora/beta patch

If the popup is opened again, won't it have the wrong constraints set? The size is only changed when the popup is opened if the layout size has changed at http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/nsMenuPopupFrame.cpp#452

	Timothy Nikkel (:tnikkel) Assignee
	Comment 50 • 12 years ago

Good point. How about if we apply the size constraints if the size changed or we are going from hidden to shown popup?

	Neil Deakin
	Comment 51 • 12 years ago

Comment on attachment 676260 [details] [diff] [review]
alternate aurora/beta patch

Did you mean to use mIsOpenChanged instead of isOpen?

	Timothy Nikkel (:tnikkel) Assignee
	Comment 52 • 12 years ago

Good point. We definitely only want to set the size constraints if isOpen is true. Otherwise we'll end up with a zero sized view whose widget has a non-zero min size constraint. But we also don't need to do it every time LayoutPopup is called while the popup is open.

It looks like the meaning of mIsOpenChanged is "mOpen changed, and it changed from false to true", so we could just check mIsOpenChanged. But I think it makes the logic clearer with the "if (isOpen)" just below it to match.

	Neil Deakin
	Comment 53 • 12 years ago

Comment on attachment 676269 [details] [diff] [review]
alternate aurora/beta patch

Since the widget's size constraints shouldn't affect the layout, I'm pretty sure that this change is ok.

> It looks like the meaning of mIsOpenChanged is "mOpen changed, and it
> changed from false to true", so we could just check mIsOpenChanged. But I
> think it makes the logic clearer with the "if (isOpen)" just below it to match.

That's correct, Checking both is redundant as mIsOpenChanged is only set to true when the popup becomes open, but you can leave it if you think it is clearer to you.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 54 • 12 years ago

Comment on attachment 676269 [details] [diff] [review]
alternate aurora/beta patch

This backs out the original regressing patch from bug 786421 and instead adjusts the size constraints of the widget to allow it to be zero sized when we are hiding it. This is an alternative fix for bug 786421, and it should be safer. Although it has had much less testing.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 786421
User impact if declined: rendering glitches in some secondary UI interactions on Aero Basic only
Testing completed (on m-c, etc.): verified that is keeps bug 786421 fixed
Risk to taking this patch (and alternatives if risky): I think this is the safest option if we want to fix this bug on beta and aurora.
String or UUID changes made by this patch: none

	Timothy Nikkel (:tnikkel) Assignee
	Comment 55 • 12 years ago

Comment on attachment 676269 [details] [diff] [review]
alternate aurora/beta patch

If we want to fix this in beta then I think we should take this patch for the upcoming beta build tomorrow to maximize testing.

[Approval Request Comment]
Same info as aurora approval request in comment 54.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 56 • 12 years ago

To be clear my plan is to land this alternate patch on beta and aurora and not nightly/mozilla-central.

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 57 • 12 years ago

Comment on attachment 676269 [details] [diff] [review]
alternate aurora/beta patch

This does sound like our safest option for beta/aurora. Please land asap so we can have this in beta 4 (going to build tomorrow) and then if we find regressions in the next week there is time to back out this combo backout/fix before we release 17.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 58 • 12 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/c3b3811b06f5
https://hg.mozilla.org/releases/mozilla-beta/rev/df94e6652a9d

	Alice0775 White
	Comment 59 • 12 years ago

(In reply to Timothy Nikkel (:tn) from comment #58)
> https://hg.mozilla.org/releases/mozilla-aurora/rev/c3b3811b06f5
> https://hg.mozilla.org/releases/mozilla-beta/rev/df94e6652a9d

This patch does not seem to fix the problem in 17beta and aurora18.0a1 .
I checked with
http://hg.mozilla.org/releases/mozilla-beta/rev/b90097a37788
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20121029153838
and
http://hg.mozilla.org/releases/mozilla-aurora/rev/9712dc86183e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20121029161938

	Timothy Nikkel (:tnikkel) Assignee
	Comment 60 • 12 years ago

(In reply to Alice0775 White from comment #59)
> This patch does not seem to fix the problem in 17beta and aurora18.0a1 .

Ok, thanks for testing. I will investigate.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 61 • 12 years ago

The alternate patch does correctly fix this bug when applied to mozilla-central, I verified using this try build http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-f9e3762d0891/try-win32/  Alice if you want to double check that the bug is fixed for you in that build that would be nice.

Best guess now is that something that landed since aurora branched is also needed to fix this bug with the alternate patch.

	Alice0775 White
	Comment 62 • 12 years ago

(In reply to Timothy Nikkel (:tn) from comment #61)
> The alternate patch does correctly fix this bug when applied to
> mozilla-central, I verified using this try build
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/tnikkel@gmail.com-
> f9e3762d0891/try-win32/  Alice if you want to double check that the bug is
> fixed for you in that build that would be nice.
> 
> Best guess now is that something that landed since aurora branched is also
> needed to fix this bug with the alternate patch.

The tryserver build works well.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 63 • 12 years ago

Backed out from aurora and beta
https://hg.mozilla.org/releases/mozilla-aurora/rev/1172c5d558e0
https://hg.mozilla.org/releases/mozilla-beta/rev/40866c9b1318

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 64 • 12 years ago

Due to timing, we'll have to target a fix for this regression to Aurora (18). At least on there is a workaround where the user can click on "done" to close the menu folder.

	Alice0775 White
	Comment 65 • 12 years ago

(In reply to Lukas Blakk [:lsblakk] from comment #64)
> Due to timing, we'll have to target a fix for this regression to Aurora
> (18). At least on there is a workaround where the user can click on "done"
> to close the menu folder.

See attachment 672123 [details], There is no "Done" button.
So, No Workaround

	Timothy Nikkel (:tnikkel) Assignee
	Comment 66 • 12 years ago

The reason the alternate patch didn't work is that we also need to backout bug 789482, a followup to bug 786421.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 67 • 12 years ago

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 789482
User impact if declined: rendering glitches in some secondary UI interactions on Aero Basic only
Testing completed (on m-c, etc.): none
Risk to taking this patch (and alternatives if risky): this is backing out a regression fix for 786421, which we are backing out in the alternate patch, so we don't need it
String or UUID changes made by this patch: none

	Timothy Nikkel (:tnikkel) Assignee
	Comment 68 • 12 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/dd53d0988e6f
https://hg.mozilla.org/releases/mozilla-aurora/rev/aee404ebbdae

	Timothy Nikkel (:tnikkel) Assignee
	Comment 69 • 12 years ago

Comment on attachment 676269 [details] [diff] [review]
alternate aurora/beta patch

Tracking 17 was removed, but I'm requesting approval if the drivers want to consider fixing this bug on beta.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 786421
User impact if declined: rendering glitches in some secondary UI interactions on Aero Basic only
Testing completed (on m-c, etc.): verified that is keeps bug 786421 fixed, been on aurora for a bit now
Risk to taking this patch (and alternatives if risky): I think this is the safest option if we want to fix this bug on beta.
String or UUID changes made by this patch: none

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 70 • 12 years ago

Comment on attachment 676269 [details] [diff] [review]
alternate aurora/beta patch

Given comment 57 (which shows the UI doesn't work for windows users as it does for Mac) and the fix being on aurora for a bit without issues, will take this for mozilla-beta.  Please land asap to make it into beta 5.

	Timothy Nikkel (:tnikkel) Assignee
	Comment 71 • 12 years ago

https://hg.mozilla.org/releases/mozilla-beta/rev/8778dcf8ffb0
https://hg.mozilla.org/releases/mozilla-beta/rev/a1a77ade717f

	Simona Badau, Desktop QA
	Comment 72 • 12 years ago

Verified on Windows 7 using Firefox 17 RC that the "Recent used folder drop down" is hidden (followed the steps from Comment 7).

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20121116115405

	Simona Badau, Desktop QA
	Comment 73 • 12 years ago

Verified as fixed on Firefox 18 beta 3 - "Recent used folder drop down" is hidden when clicking on an empty area.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20121205060959

	Christian
	Comment 75 • 7 years ago

I still get a problem that sounds like this issue isn't fixed (I came here from Bug 801813). Occasionally if I have the location bar suggestions up for a while before doing something to cause it to close, the black shadow line along the bottom remains on my desktop.  It also happens with the search bar if I leave the suggestions up too long, but the shadow s slightly thicker and L-shaped (as if the L were tipped on its side). The former (location bar) artifact tends to stay "behind" windows, but the latter (L-shaped search bar) artifact stays above windows.

I can sometimes deliberately cause the artifact by getting one of the menus up and switching to a different application without letting the popup close first.

These artifacts persist through browser restarts, or even DWM/Explorer restarts. The only way I can get them to go away is logging out and back in.

Problem has remained through two video driver updates and many Firefox updates, and no other applications have ever had this issue.

You can see an example of the location bar artifact in this screenshot: https://www.dropbox.com/s/sqthsydgxqy9usm/firefoxartifact.png?dl=0

Graphics
Features
Compositing                   Direct3D 11
Asynchronous Pan/Zoom         none
WebGL Renderer                Google Inc. -- ANGLE (Intel(R) HD Graphics 4000 Direct3D11 vs_5_0 ps_5_0)
WebGL2 Renderer               Google Inc. -- ANGLE (Intel(R) HD Graphics 4000 Direct3D11 vs_5_0 ps_5_0)
Audio Backend                 wasapi
Direct2D                      true
DirectWrite                   true (10.0.14393.1198)
GPU #1
Active                        Yes
Description                   Intel(R) HD Graphics 4000
Vendor ID                     0x8086
Device ID                     0x0166
Driver Version                10.18.10.4425
Driver Date                   4-4-2016
Drivers                       igdumdim64 igd10iumd64 igd10iumd64 igdumdim32 igd10iumd32 igd10iumd32
Subsys ID                     22118086
RAM                           Unknown
Diagnostics
ClearType Parameters          Gamma: 2.2 Pixel Structure: RGB
AzureCanvasAccelerated        0
AzureCanvasBackend            direct2d 1.1
AzureContentBackend           direct2d 1.1
AzureFallbackCanvasBackend    skia
ClearType Parameters          Gamma: 2.2 Pixel Structure: RGB
Decision Log
D3D9_COMPOSITING              disabled by default: Disabled by default
GPU_PROCESS                   unavailable by runtime: Multi-process mode is not enabled