Can you provide some example? Thanks
(In reply to Vlad [QA] from comment #1) > Can you provide some example? > Thanks In what form? A screenshot?
I guess that’s not a doorhanger; maybe it’s called a notification bar.
Compare: bug 691849.
(In reply to Aleksej [:Aleksej] from comment #4) > Compare: bug 691849. Exact same behaviour I got in Firefox 16 and below except that the bar NoScript creates is at the top of the content region rather than the bottom. (So the screenshot that bug provides is a reasonable example of what older versions did) Firefox 17 could be said to fix that problem, but it does it by, instead, force-resizing the OS-level browser window to fit non-wrapping content that, in my case, is about five times as wide as my desktop. (Which I consider worse)
I just noticed that, now that Aurora channel has me on build 20120913180634, the browser window undoes its self-resizing when the problematic notification is hidden. (eg. by navigating or closing the tab) Still not ideal, but at least I don't have to struggle to manually undo a resize operation that could leave the window 5 or 6 times as wide as my desktop.
(In reply to Stephan Sokolow from comment #6) > I just noticed that, now that Aurora channel has me on build 20120913180634, > the browser window undoes its self-resizing when the problematic > notification is hidden. (eg. by navigating or closing the tab) > > Still not ideal, but at least I don't have to struggle to manually undo a > resize operation that could leave the window 5 or 6 times as wide as my > desktop. Actually, I just realized that may just be how my window manager (Openbox) handles maximized windows. The app I'm using to test is a prototype with no logout button, so I'll try to remember to test with Firefox unmaximized next time I restart the browser.
Worse than I suspected. With Firefox not maximized, not only does it resize the window and leave it that way, it also moves the window. (It was in the middle of my left-hand monitor. When I clicked the huge link NoScript's ABE blocked, the notification moved the window to fill my right-hand monitor.)
Created attachment 663252 [details] Minimal test case including instructions Here. Maybe the problem will be more clear if I offer a simple test case that'll demonstrate the problem with two clicks. (Plus whatever time it takes you to install NoScript)
Created attachment 663253 [details] Same testcase uploaded with another attempt at setting text/html mimetype Either I wasn't paying attention to Bugzilla has a bug in the mimetype selector.
Attachment #663252 - Attachment is obsolete: true
Created attachment 663255 [details] Testcase uploaded with mimetype auto-detect Ok. Bugzilla has a bug in the "select from list" mimetype selector.
Attachment #663253 - Attachment is obsolete: true
Attachment #663255 - Attachment mime type: text/plain → text/html
I can reproduce. I suspect it might be a NoScript bug, though. (It might be noscript's responsibility to make that content area be "overflow:hidden" or "text-overflow:ellipsis" or something.) CC'ing NoScript author Giorgio Maone.
Created attachment 707662 [details] screenshot Here's a screenshot of the (crazy-wide) window that the testcase produces for me (w/ Nightly, on Ubuntu 12.10 using Gnome Shell) Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20130129 Firefox/21.0
(In reply to Daniel Holbert [:dholbert] from comment #12) >(It might be > noscript's responsibility to make that content area be "overflow:hidden" or > "text-overflow:ellipsis" or something.) It's not the first time I try to tackle this problem, and unfortunately it's not that simple. Setting overflow:hidden, text-overflow:ellipsis or both on either the <notification> element itself or its <description> XBL descendent has no effect. I even tried to force wrapping by inserting a non-visible space ("\u200B") every 20 characters, but this technique, which works fine for doorhangers and prompt box, doesn't affect notifications. In facts, in NSA++ (on Android) I switched to doorhangers and this is not an issue anymore, but switching on the desktop would be problematic yet.
Summary: Starting in Firefox 17, long doorhangers force-resize the window → Starting in Firefox 17, long notification bars force-resize the window
Hello Reporter, I tried to duplicate the problem on FF 17 on Ubuntu 32 bit and I was able to see the problem. However, when I tried it on the latest released versions of FF (43.0.4) and the latest nightly build 46.0a1, I found that problem was fixed. Below is one of the FF version on which I found your issue to be working fine. Name Firefox Version 46.0a1 Build ID 20160113030208 Update Channel nightly User Agent Mozilla/5.0 (X11; Linux i686; rv:46.0) Gecko/20100101 Firefox/46.0 Can you please upgrade your FF version to the latest released version if you have not done so and provide your confirmation that this issue stands fixed now? Thank You!
Component: Untriaged → General
Product: Firefox → Core
Created attachment 8707742 [details] New screenshot Well, it doesn't force-resize the window anymore, but it does force the browser chrome to exceed the window dimensions in an "overflow: hidden" sort of way unless you manually resize it up to what it used to force. (Note the top-right corner of that window. The tab bar and address bar are much wider than the window and get clipped down.
I was focusing more towards the original issue in which you stressed more towards the window force-resize problem. Agreed that it is no more an issue but it does force firefox to exceed the window dimensions in an "overflow: hidden" sort of way even with the newer versions. Changing the status of the defect to "New".
Status: UNCONFIRMED → NEW
Ever confirmed: true
This feels like a browser UI issue, not a core issue.
Component: DOM: Core & HTML → Theme
Product: Core → Firefox
Version: 17 Branch → unspecified
You need to log in before you can comment on or make changes to this bug.