Closed
Bug 597769
Opened 14 years ago
Closed 14 years ago
Consolidate urlbar overlink transitions
Categories
(Firefox :: Address Bar, defect)
Firefox
Address Bar
Tracking
()
RESOLVED
INVALID
People
(Reporter: dao, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
patch
|
adw
:
review-
|
Details | Diff | Splinter Review |
No description provided.
Attachment #476583 -
Flags: review?(adw)
Comment 1•14 years ago
|
||
Comment on attachment 476583 [details] [diff] [review]
patch
I'd very much like to make this simplification, and my original proof-on-concept patches worked like this, but unfortunately I found that it causes the origin URL to noticeably and unacceptably flicker. Don't you notice it too? Transitioning the text color rather than the opacity was the best-looking approach I could find. (See bug 587908 comment 78.)
Reporter | ||
Comment 2•14 years ago
|
||
(In reply to comment #1)
> Comment on attachment 476583 [details] [diff] [review]
> patch
>
> I'd very much like to make this simplification, and my original
> proof-on-concept patches worked like this, but unfortunately I found that it
> causes the origin URL to noticeably and unacceptably flicker. Don't you notice
> it too? Transitioning the text color rather than the opacity was the
> best-looking approach I could find. (See bug 587908 comment 78.)
I didn't notice it with this patch, no. It may be platform-specific, but I'm not sure I see why using transparency in the color instead of on the node would make a difference.
Btw, my motivation here was bug 451833. color:transparent doesn't affect the ranges created by the value formatter.
Comment 3•14 years ago
|
||
Comment on attachment 476583 [details] [diff] [review]
patch
(In reply to comment #2)
> I didn't notice it with this patch, no. It may be platform-specific, but I'm
> not sure I see why using transparency in the color instead of on the node would
> make a difference.
Maybe. For me, on OS X, it definitely looks bad. I can only guess why: node opacity isn't smart about subpixel rendering of whatever text the node might contain, while text color is.
I hope we can find a way to simplify this so that it looks good everywhere and doesn't block your bug, but this patch causes noticeable flicker. Perhaps we should ask a graphics or layout person to either help us with the opacity flicker or support color:transparent for value formatter ranges.
Attachment #476583 -
Flags: review?(adw) → review-
Reporter | ||
Comment 4•14 years ago
|
||
Does applying a persona make a difference for you?
Comment 5•14 years ago
|
||
No, the flicker still occurs.
Reporter | ||
Comment 6•14 years ago
|
||
Then it wouldn't be subpixel vs. grayscale rendering, I think, since opacity on the textbox should already disable subpixel rendering: http://mxr.mozilla.org/mozilla-central/source/browser/themes/pinstripe/browser/browser.css#52
So maybe there's something wrong with the timing functions. I can see how there would be artifacts if there's too much overlap between the fade-out and the fade-in.
Comment 7•14 years ago
|
||
OK. That was my thought too. I played around with lots of combinations of timing functions, and I'm still not sure why linear functions on both fade in and out didn't look good, but maybe you can find a solution.
Comment 8•14 years ago
|
||
(In reply to comment #6)
> Then it wouldn't be subpixel vs. grayscale rendering, I think, since opacity on
> the textbox should already disable subpixel rendering
Opacity doesn't disable subpixel rendering in this case. I'm not completely sure why, but maybe we detect that the text is still on top of opaque background inside its opacity surface, so we still enable subpixel rendering because we can.
Reporter | ||
Updated•14 years ago
|
Assignee: dao → nobody
Status: ASSIGNED → NEW
Reporter | ||
Updated•14 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•