Closed
Bug 913227
Opened 11 years ago
Closed 11 years ago
paint flashing shows url bar painting when moving mouse in ux-branch. doesn't happen in nightly
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: taras.mozilla, Unassigned)
References
Details
(Whiteboard: [Australis:P5][Australis:M?])
Comment 1•11 years ago
|
||
I can reproduce this on Windows 7 as well.
Updated•11 years ago
|
Blocks: australis-tabs-perf
Comment 2•11 years ago
|
||
The border of the URL bar is being changed on hover, which (I believe) is causing it to repaint. This is also true on m-c Nightly.
The overpainting going on near the location panel anchor is a little distressing. That's not present on m-c Nightly.
Comment 3•11 years ago
|
||
Marking as P5 until we know that fixing this will help us in a significant way on the benchmarks that we are tracking.
Whiteboard: [Australis:P5][Australis:M?]
Comment 4•11 years ago
|
||
I don't see this anymore on Mac. mconley, can you test win7 again?
(I did file bug 946013 for the other issue described in comment 2)
Flags: needinfo?(mconley)
Comment 6•11 years ago
|
||
Is the theory in comment 2 correct? (I don't have a windows machine handy)
If so, why do we only have a border effect on Windows?
Comment 7•11 years ago
|
||
Is this hover effect actually intentional or just a regression/bug/fallout from bug 755598?
Comment 8•11 years ago
|
||
It's not a regression from bug 755598, it's existed since we implemented the conditional forward button.
It happens on Windows for two reasons: 1, we have a border-on-hover effect on windows for toolbarbuttons, and 2, parts of the toolbar item theme are not opaque due to lwthemes.
Comment 9•11 years ago
|
||
(In reply to Jared Wein [:jaws] (Away 20 Dec to 2 Jan) from comment #8)
> It's not a regression from bug 755598, it's existed since we implemented the
> conditional forward button.
>
> It happens on Windows for two reasons: 1, we have a border-on-hover effect
> on windows for toolbarbuttons, and 2, parts of the toolbar item theme are
> not opaque due to lwthemes.
But on pre-australis the hover effect was limited to hovering the back/fwd-button. Now it appears when hovering the navbar. However, I thought that was the same cross-OS (certainly the same happened on OS X when I created the patches for this problem in bug 700363), and so I inferred that the points comment #7 and comment #2 made were about a different hover on the actual, entire URL bar, on Windows, rather than the toolbarbutton's hover showing through. That's also what the video from comment #0 seemed to be about, although maybe we're invalidating the entire urlbar frame because it is translucent and we're changing stuff underneath it and that's what you're saying. Maybe I misunderstood the aforementioned comments? I can't test this myself right now because my Windows machine is in a box in a truck 'somewhere'. :-\
Comment 10•11 years ago
|
||
(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #6)
> Is the theory in comment 2 correct? (I don't have a windows machine handy)
Yes.
> If so, why do we only have a border effect on Windows?
Because that sort of hover effect is native on Windows but not on other platforms.
Comment 11•11 years ago
|
||
Sounds like this is WONTFIX, then, unless we want to get rid of the hover effect. Seems to me that the benefits are greater than the costs; feel free to REOPEN if you disagree.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•