Setting the width attribute by default along with flex makes layout behave consistently for profiles where the splitter has been touched and profiles where it hasn't been touched.

Comment on attachment 567449 [details] [diff] [review] patch This seems to make the search bar much narrower by default in new profiles: Without patch: http://cl.ly/3X3y0W2Z0u1h1r3y0s3b With patch: http://cl.ly/0m1L0211371S1q3J1K1A

Hm, I did the same thing (comparing two screenshots) and there was no difference...

[Triage Comment] Once this is reviewed and landed on m-c, please nominate for aurora approval.

updated to avoid the setTimeout

Comment on attachment 584540 [details] [diff] [review] patch v3 Review of attachment 584540 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/base/content/browser.js @@ +2607,5 @@ > splitter.parentNode.removeChild(splitter); > } > > +function setUrlAndSearchBarWidthForConditionalForwardButton() { > + // Woraround for bug 694084: Showing/hiding the conditional forward button resizes nit: s/Woraround/Workaround

Comment on attachment 584540 [details] [diff] [review] patch v3 Review of attachment 584540 [details] [diff] [review]: ----------------------------------------------------------------- maybe i'm just not familiar enough with the code here, but this seems like something that should be fixable with css alone. why all this code around a sizing issue?

This could be fixed in CSS if percenrage widths worked with the xul flexbox layout. Unfortunatrly, they don't.

(In reply to Jared Wein [:jwein and :jaws] from comment #7) > nit: s/Woraround/Workaround http://hg.mozilla.org/integration/mozilla-inbound/rev/8a0d9d68c5b0

Comment on attachment 584540 [details] [diff] [review] patch v3 [Approval Request Comment] Regression caused by (bug #): bug 674744, bug 677027, bug 682534 User impact if declined: distracting movement when clicking the back button Testing completed (on m-c, etc.): baking on mozilla-central Risk to taking this patch (and alternatives if risky): no risk anticipated

Comment on attachment 584540 [details] [diff] [review] patch v3 [Triage Comment] The user impact does not appear significant enough to meet the criteria for beta approval. That being said, we can expedite pushing this to our GA users by landing on Aurora.

Comment on attachment 584540 [details] [diff] [review] patch v3 Requesting approval again. This is a regression in one of the most used parts of the primary UI. We also know this can be annoying -- I don't know about feedback from beta users, but nightly users asked how to disable the feature because of this.

(In reply to Dão Gottwald [:dao] from comment #16) > Comment on attachment 584540 [details] [diff] [review] > patch v3 > > Requesting approval again. This is a regression in one of the most used > parts of the primary UI. We also know this can be annoying -- I don't know > about feedback from beta users, but nightly users asked how to disable the > feature because of this. We'll discuss this at today's channel meeting. It's difficult to make the case for taking this on our second-to-last or last beta given how long we've known about this issue. If it were that critical to our users, I would have expected us to land a patch much sooner.

Adding qawanted since it was noted in the channel meeting that it has landed on aurora and trunk.

(In reply to Marcia Knous [:marcia] from comment #19) > Adding qawanted since it was noted in the channel meeting that it has landed > on aurora and trunk. Did you mean to add the keyword instead of whiteboard tag? Also, verifyme instead of qawanted?

Comment on attachment 584540 [details] [diff] [review] patch v3 Discussed in triage - approved, but we worry about taking changes to primary UI in a late beta. Please land it quickly, and think a little harder about cases where this could break, so that QA can test. (Very small window sizes? Using the resizer afterwards? Extensions that care about where they live in the toolbar?)

On Linux-x86_64: bug: Nightly 20111118 Firefox/11.0a1 WFM: 20120202 Firefox/13.0a1 and 11.0b1 bug: Aurora 20111118 Firefox/10.0a2 WFM: 20120202 Firefox/12.0a2

Tested in Firefox 11 beta 2 on Ubuntu 11.04, Win XP and OSX 10.6.8: Build identifier: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0 Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0 Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20100101 Firefox/11.0 The search box does not change it's dimensions when the forward button is overlapped or not by the location bar.