[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.15pre) Gecko/2008052503 BonEcho/2.0.0.15pre] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9] (release) (W2Ksp4) No bug. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008052406 Minefield/3.0pre] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008052501 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) (Noticed while testing bug 414021.) 1. Load <about:>. (for example) 2. Shrink the window size. 2r. At some point, vertical and horizontal scrollbars appear: fine. 3. Continue shrinking. 3r. When the size at which the location bar can't shrink anymore is reached, the scrollbars become "fixed-positioned", then start to disappear if the window is made smaller. This is most noticeable with the vertical scrollbar, which soon disappears entirely.

Related to bug 312247?

Bug 312247 comment 33: {{ David Baron [:dbaron] 2008-01-15 21:51:40 PDT This really could use a regression test. It's been fixed in the past, and regressed at least once, if not more than once. }} If they are the same bug, then: *SeaMonkey was not fixed. *Firefox regressed again.

WFM, Firefox 3.0 RC1 on Linux with a clean profile.

Bug 312247 wasn't fixed. Only wallpapered for individual occurences. Try this: {scary} hbox.textbox-input-box { overflow-x: hidden; } {less scary} #urlbar hbox.textbox-input-box { overflow-x: hidden; } This will work until you reach another limitation. I'm not sure what, possibly the label in the #statusbar-display. Also see Attachment 292852 [details] [diff] in Bug 312247

Assignment accidentally removed during component change. Serge, the fix for SeaMonkey navigator/browser is relatively simple so you might want to take this bug yourself. Since Bug 312247 was wallpapered over and marked FIXED. You might want to file a new bug targetting Gecko 1.9.1 though and cc dbaron (q.v. Bug 312247 Comment 19)

why does this block bug 312247?

(In reply to comment #6) > why does this block bug 312247? Because I thought they may be duplicates ... but they are not.

this regressed between trunk builds 2007-01-16-08 and 2007-01-17-09

See Bug 391358 Comment #18 (and 19)

> See Bug 391358 Comment #18 (and 19) Lucas, try this CSS on the textbox-input-box elements of both the Firefox urlbar and the google searchbox. hbox.textbox-input-box { overflow-x: hidden; }

With this CSS all works perfectly, both min-width properties and scrollbars. The only problem I still see is with slidebars, as password manager notifications to save login data. Two little suggestions: 1. I think it's useful to add a button for a dropdown menu also for the navigation toolbar and statusbar, as in bookmarks toolbar 2. textboxes should have a minimum width, since urlbar and searchbox can be shrank to an useless width.

(In reply to comment #10) > hbox.textbox-input-box { > overflow-x: hidden; > } Why this code is not still added to Fx?

> Why this code is not still added to Fx? Because this code is in the SeaMonkey/Mozilla Suite component.

I mean this *bug* is in the SeaMonkey component.

See bug 391358 for a similar problem in Firefox.

This bug was fixed for Firefox in Bug 312247

(In reply to comment #16) > This bug was fixed for Firefox in Bug 312247 See comment 4 (for example) !

Jag, feel free to retake this bug if you're interested in fixing it.

The core bug 204743 was reported in 2003 and nobody seems to have worked on it until today. Firefox chose to wallpaper over it in Bug 312247. I suggest that we do the same until the core bug is fixed.

Comment on attachment 366528 [details] [diff] [review] Patch v1.0 Wallpaper over the problem. >+ min-width: 8em; Why this? We have other textboxes in toolbars :-(

>>+ min-width: 8em; > Why this? Without a min-width, in classic when you scrunch up the urlbar too much various elements start overlapping each other. It looks really weird. I just picked 8em based on the urlbar not looking to squished. You may need a different min-width if your screen resolution is different. > We have other textboxes in toolbars :-( As I said this is a wallpaper patch for navigator.xul. Nobody has complained about other windows yet.

s/to squished/too squished/

Comment on attachment 366528 [details] [diff] [review] Patch v1.0 Wallpaper over the problem. How about putting the overflow on the .textbox-input-box instead?

> (From update of attachment 366528 [details] [diff] [review]) > How about putting the overflow on the .textbox-input-box instead? That worked for Firefox. See Comment 4. But when I tried it in SeaMonkey Classic I got the same overlapping elements effect when the URLbar got too narrow. Perhaps it's just one of those things that work for you but nobody else?

(In reply to comment #24) > > (From update of attachment 366528 [details] [diff] [review]) > > How about putting the overflow on the .textbox-input-box instead? > That worked for Firefox. See Comment 4. Sorry, I hadn't read the whole bug, and I'd glanced at other bugs but not seen .textbox-input-box used. But I didn't get any "overlapping elements".

Let me do some tests. It might depend (Classic) on the OS theme again.

OK. I don't see this problem using the OS classic theme, only when using (several variants) of the XP theme and any of {.textbox-input-box|.textbox-input|.autocomplete-textbox-container}, e.g. .autocomplete-textbox-container { overflow-x: hidden; min-width: 8em; } Moving up the DOM hierarchy I finally ended up with using |#urlbar|

OK, I'll try it with Luna tonight.

Filed bug 482955 on the bug when using Luna.

Now that the Luna bug (Bug 482955) is fixed we can apply the css directly on the .text-input-box

Comment on attachment 375454 [details] [diff] [review] Wallpaper Patch v2.0 [Checkin: Comment 34] >-window[chromehidden~="toolbar"] #nav-bar-buttons, >-window[chromehidden~="toolbar"] #print-button { >- display: none; Presumably toolbar customisation makes these rules silly.

>>-window[chromehidden~="toolbar"] #nav-bar-buttons, >>-window[chromehidden~="toolbar"] #print-button { >>- display: none; > Presumably toolbar customisation makes these rules silly. Well #nav-bar-buttons doesn't exist currently; and #print-button now has class="... chromeclass-toolbar-additional" so the above rule is redundant. But otherwise, yes.

Comment on attachment 375454 [details] [diff] [review] Wallpaper Patch v2.0 [Checkin: Comment 34] http://hg.mozilla.org/comm-central/rev/281f13422910

Comment on attachment 375454 [details] [diff] [review] Wallpaper Patch v2.0 [Checkin: Comment 34] (In reply to comment #33) > http://hg.mozilla.org/comm-central/rev/281f13422910 Argh: http://hg.mozilla.org/comm-central/rev/16299ba28bdf !