Leftover yellow in the url bar when typing while viewing an https site

VERIFIED FIXED in Firefox 3 beta4



10 years ago
10 years ago


(Reporter: dcamp, Assigned: johnath)


Firefox 3 beta4
Mac OS X
Dependency tree / graph
Bug Flags:
blocking-firefox3 +

Firefox Tracking Flags

(Not tracked)



(2 attachments)



10 years ago
Created attachment 300549 [details]

* 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).


10 years ago
Duplicate of this bug: 415052
Flags: blocking-firefox3?
Duplicate of this bug: 414780
Flags: blocking-firefox3? → blocking-firefox3+

Comment 3

10 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

10 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.

Comment 5

10 years ago
Created attachment 305538 [details] [diff] [review]
remove pageproxystate selectors from location-bar styles

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
Duplicate of this bug: 419314
Blocks: 397723
Hardware: PC → All


10 years ago
Depends on: 419772
Target Milestone: --- → Firefox 3 beta4


10 years ago
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 7

10 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.
You need to log in before you can comment on or make changes to this bug.