User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a7pre) Gecko/2007071305 Minefield/3.0a7pre Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a7pre) Gecko/2007071305 Minefield/3.0a7pre Firefox/3.0 Go to the URL www.cnn.com or www.msnbc.com and click on the RSS Icon. These sites offer a multiple choice of feeds. Click either and note the Domain Highlighting goes away. Clicking Back then results in the location bar no longer displaying the Domain Highlight across all tabs. Clicking on the location bar and then in the webpage body restores the Domain Highlighting. Web pages that offer only a single link when clicking the RSS feed does not seem to break the Domain Highlight. Same occurs if you hover over the location bar and let it turn all black, then drag the favicon to the bookmarks bar, the Domain Highlighting is lost. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: Domain Hightlighting disappears leaving the user without the feature. Expected Results: Domain Hightlighting should not disappear leaving the user without the feature. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a7pre) Gecko/2007071305 Minefield/3.0a7pre Firefox/3.0 ID:2007071305

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a7pre) Gecko/2007071305 Minefield/3.0a7pre ID:2007071305 I see this too --> NEW

This is because the mouseout event isn't dispatched if you open the Feed icon's popup menu.

This avoids the whole problem by switching to the styled view as soon as you move the mouse over the Feed icon (and others). Note that |this._plain = false;| in the current code doesn't do anything. That has to be |this._formatted = true;|. Also, I'm now setting that directly in _prettyView instead of _initPrettyView. Otherwise |if (!this.plain && !this._isMouseOverAddress(event))| would malfunction when moving the mouse over the favicon.

mouseout was not working as expected

Oops, v3 was nonsense.

Does this affect the location bar pretty-print display for characters and spaces as well, or just the domain highlighting?

This affects the pretty-print display in any case. (Domain highlighting was just one way to style it.)

Then yes, it blocks :)

_isMouseOverElement removed

there's no good reason to use _inputBox instead of inputField

indention fixed

Can you please update the new target milestone? Thanks.

The latest patch still has trouble dealing with long URLs and small windows.

nasty ... but not as nasty as flex="9999"

width="1" is needed for very long URLs like http://tinyurl.com/3ykhdb

I still see the bug from my screenshot (attachment 282692 [details]) with the latest patch.

Hm, I thought I didn't. Will recheck.

Here's what I see. I've obviously modified the urlbar in other ways, but I don't think that should make a difference. I will try a clean build + profile. Note that I did see the bug with the previous patch.

Comment on attachment 282706 [details] [diff] [review] patch v4.4 Ok, seeing it now. It depends on whether the protocol is hidden.

moving out bugs that don't need to block b1

Comment on attachment 283033 [details] [diff] [review] patch v4.5 >Index: browser/base/content/urlbarBindings.xml > <method name="_initPrettyView"> >+ this._formattedURL.hidden = false; >+ this._prePath.maxWidth = >+ this._prePath.width = ""; >+ this._prePath.flex = 0; >+ this._prePath.maxWidth = > this._prePath.width = this._prePath.boxObject.width; >+ this._prePath.flex = 1; This is the hack used to get the sizing right, presumably? Could you add a comment explaining it? >Index: browser/themes/pinstripe/browser/browser.css >Index: browser/themes/winstripe/browser/browser.css I wonder if we want to increase the url bar's min-width given the way this looks with small windows. Having the host just end abruptly without a "..." could potentially be a spoofing risk. Followup bug?

(In reply to comment #24) > This is the hack used to get the sizing right, presumably? Could you add a > comment explaining it? I'll add one. (I realize that my code could use more comments in general.) > I wonder if we want to increase the url bar's min-width given the way this > looks with small windows. Having the host just end abruptly without a "..." > could potentially be a spoofing risk. Followup bug? I don't think |crop| can be used there, and increasing the minimum width will cause the search bar to be pushed off the window earlier, esp. with Larry. But it's worth tracking anyway, so yes, I'll file a bug later.

thanks for the review, Gavin.

Checking in browser/base/content/urlbarBindings.xml; /cvsroot/mozilla/browser/base/content/urlbarBindings.xml,v <-- urlbarBindings.xml new revision: 1.34; previous revision: 1.33 done Checking in browser/themes/pinstripe/browser/browser.css; /cvsroot/mozilla/browser/themes/pinstripe/browser/browser.css,v <-- browser.css new revision: 1.85; previous revision: 1.84 done Checking in browser/themes/winstripe/browser/browser.css; /cvsroot/mozilla/browser/themes/winstripe/browser/browser.css,v <-- browser.css new revision: 1.105; previous revision: 1.104 done

This regressed perf on mac only. Before: Tp:148ms Tp2:101.575ms Tdhtml:523ms Txul:149ms Ts:851ms After: Tp:165ms Tp2:105.5875ms Tdhtml:523ms Txul:155ms Ts:871ms I didn't back it out yet, but I will tomorrow if the fix isn't obvious.

Unless |crop| is much more expensive than the scrollbox was (on Mac only?!) it could only be this: - this._plain = false; this._protocol.hidden = false; - this._presentationBox.hidden = false; - this._prePath.width = ""; - if (this._protocolHidden) { + this._formattedURL.hidden = false; + this._prePath.maxWidth = + this._prePath.width = ""; + this._prePath.flex = 0; + + this._prePath.maxWidth = this._prePath.width = this._prePath.boxObject.width; + this._prePath.flex = 1; + + if (this._protocolHidden) this._protocol.hidden = true; - } Because I expect boxObject.width to trigger layout. But an 11% Tp regression? And again, Mac only? That's ... interesting, to say the least.

This would help if the location changes while staying on the same host. However, I don't see how this could save 17ms on pageload. And I assume that Tp is about pages from different hosts anyway ...

Latest numbers: Tp:143ms Tp2:96.2ms Tdhtml:398ms Txul:130ms Ts:853ms Not sure what's going on there.

Backed out due to mac-only perf regression.

With the change from comment 31 and overflow:-moz-hidden-unscrollable instead of overflow:hidden. I don't really know where the slowdown on Mac originated, any hint is welcome.

Thanks to overflow:-moz-hidden-unscrollable, I can revert _initPrettyView to something simpler if the protocol isn't hidden.

Litmus triage team: test case to be added in Litmus by Tomcat

Dao, could you give the reasoning behind resolving this WONTFIX?

i assume this was marked wontfix by accident, reopening

There won't be a patch landing here, as there won't be a 'Domain Highlight'.

ok,sorry for the span than, resetting wontfix

Verified