Closed
Bug 415000
Opened 17 years ago
Closed 17 years ago
Leftover yellow in the url bar when typing while viewing an https site
Categories
(Firefox :: Theme, defect, P3)
Tracking
()
VERIFIED
FIXED
Firefox 3 beta4
People
(Reporter: dcamp, Assigned: johnath)
References
Details
Attachments
(2 files)
(deleted),
image/png
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
* Visit an https site, turning the url bar yellow. * Focus the url bar and start typing. Most of the url bar will turn white, but there's a bit of yellow leftover on the left (see attached screenshot).
Updated•17 years ago
|
Flags: blocking-firefox3?
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Assignee | ||
Comment 3•17 years ago
|
||
So I see two ways to fix this: 1) Stop reverting the yellow on edit. This behaviour was introduced semi-recently by bug 398020, so users aren't counting on it, and I'm not sure I see the value. CC'ng Dao in case he remembers the motivation, I know I've asked him about it before but it's not sticking. 2) Keep the new behaviour on edit, and update the endcap images to match. Doing this properly will require someone with access to the source graphics, and if we're adding more url bar graphics, we should really just composite them into one image and update the rules to use -moz-image-region instead, likely picking up a small perf win in the process. I think 1 is the better approach, modulo Dao's opinion on the subject. If the white-on-edit behaviour was added for security reasons (e.g. "the url bar no longer reflects the site you're visiting") then I definitely think we can revert it, since the chrome is still full of security indicators and we don't want them all to blink off and on whenever you edit. If the white-on-edit behaviour was added for theming reasons (e.g. "the go button is more of a pain if the location bar can be different colours") then we'll have to weigh the relative cost of making either change, at this point. CC'ng a couple other people I've spoken to about it, but I'll ping Dao and Kevin G over the course of today, to try and nail this down. Giving it P3 status in the meantime, because while we wouldn't absolutely refuse to ship with this bug unfixed, it looks sloppy.
Blocks: 398020
Priority: -- → P3
Comment 4•17 years ago
|
||
Depending on the pageproxystate, we're changing the buttons within the location bar and we're invalidating the favicon -- which is now part of the identity UI --, so it makes sense to update the yellow background as well. This was originally suggested by mconnor. If it's somehow hard to get this right on pinstripe, then please ask mconnor and if he agrees, just make pinstripe ignore the pageproxystate when setting the yellow background.
Assignee | ||
Comment 5•17 years ago
|
||
I don't think it makes sense to revert this change on only one platform, giving mac and windows/linux different location bar behaviours wrt SSL state. This patch reverts the behaviour to what it was before bug 398020. That is, the location bar only changes treatment when urlbar |level| attribute is changed. All of this though is less desirable than just doing the currently proposed thing in bug 417844 comment 14. I'm attaching the WIP patch as a just-in-case, since the solution in bug 417844 requires new graphics from our Mac themers. If we get that bug resolved, this one should be resolved as well.
Assignee: nobody → johnath
Status: NEW → ASSIGNED
Updated•17 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 7•17 years ago
|
||
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008022704 Minefield/3.0b4pre.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•