391358 - Content viewport does not shrink below toolbar/status bar min width

Status: RESOLVED DUPLICATE of bug 312247

(Firefox :: Theme, defect)

Description

[Johan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

When using the min-width property on an element it does not make use of the set min-width. For example: A div with a min-width of 300px will stop contracting at somewhere around 640-680px. Made some experiments and noticed that the actual min-width of the element will change depending on what margin and/or padding is set to the html or body elements. Maybe even to any surrounding containers, did not try that though.

Reproducible: Always

Steps to Reproduce:
1. Open attached testcase
2. Resize browser window to truncate the div

Actual Results:  
Min-div is of no use when resizing the browser window. The actual min-width is far too wide.

Expected Results:  
Div should be no wider than 300px as set in CSS.

Try adding body { margin: 50px } to the CSS and the actual min-width will change. A margin of about 230px will make the min width will make the actual min-width narrow down to the set-min width when resizing though.

Comment 1

[Johan]

Attachment: Example file to reproduce Min-width error.

Comment 2

[Mats Palmgren (inactive)]

Works for me, Firefox 2.0.0.6 on Vista and Linux.

Does it work if you start Firefox in Safe Mode?
(it temporarily disables add-ons and themes, this test will help us narrow
down the cause of the problem) --  See http://kb.mozillazine.org/Safe_Mode

Comment 3

[Johan]

Tried it in Safe Mode and the problem seem to be with add-ons.
The min-width bug only appear when several add-ons are activated at the same time.
For example if I have more than 14 add-ons activated, adds about 10 pixels to a min-width of 300px, If I activate even more add-ons, it gets even worse.

If I use a min-width of 100px, I have to go down to 12 add-ons activated to get correct results.

Experimented with activating and de-activating different add-ons and it looks just it appear with any add-on, if there are too many add-ons activated simultaneously.

Comment 4

[Samuel Sidler (old account; do not CC)]

Since this is a problem with add-ons, resolving as INVALID.

Johan, feel free to isolate which of the add-ons are causing this and contact their authors with a bug report. This being caused by the sheer number of enabled add-ons is very, very unlikely.

Comment 5

[Johan]

Tried activating a few add-ons.
Problem occured.
Tried de-activating them one by one until the problem was gone.
Now I activated that very same add-on and the problem was indeed present.
Tried de-activating another add-on, the problem was gone.
Repeated this procedure several times. All the time different add-ons activated/de-activated and the problem was there most of the time.

Did the same test to a totally different set of add-ons, same result.
Only appear when Firefox reach a certain amount of activated add-ons. The amount will be different depending on which add-ons that are enabled at the same time. Also the total amount of pixels that this bug adds to min-width will be different depending on which add-on that trigger the bug, and pixels will also increase as you activate more add-ons.

Result: Problem occur with different add-ons activated, different amount of add-ons needed to trigger the bug, depending on add-ons activated.

This, for me, as a non-developer/coder is totally impossible to debug because of the inconsistency of the results each time. Could indeed be that the bug is present add-ons as you say, but if so in a LOT of add-ons. And if that is the case, isn't that more of a Firefox issue then?

Comment 6

[Mats Palmgren (inactive)]

Johan, are the add-ons adding a new toolbar(s)?
Does the (viewport) horizontal scrollbar appear at the same time the problem occurs?
Does you get a horizontal scrollbar on about:blank with a small window width?

Comment 7

[Johan]

No new toolbar.
No horizontal scrollbar during problem testing.
No horizontal scrollbar on about:blank.

Comment 8

[Mats Palmgren (inactive)]

It's odd that an add-on would have this effect...
Could you list the smallest number of add-ons required to reproduce the bug
and I'll see if it occurs for me too.
(preferably add-ons that are cross-platform)

Comment 9

[Johan]

After lots of experimenting I think the problem only appear when something is added to the statusbar.

I get the bug by just using: Alexa Sparky 1.1
Only required to activate that add-on to see the problem.

And by using: HTML Validator 0.8.3.9
              NoScript 1.1.6.12
              Screen grab! 0.93
              ShowIP 0.8.05

If you activate the four add-ons above, the problem occurs, but if you de-activate ANY of them, the problem is gone. Quite hard to narrow it down to just one add-on then.

Probably got more add-ons that will trigger the bug but I think this will show the problem. (If it's not just my browser having them)

You can reproduce the bug by using the new sample included. Just shrink the window to squeeze the div down to 100px.

Comment 10

[Johan]

Attachment: Reproduce bug

Shrink browser window down and try to make the div 100px

Comment 11

[Johan]

While using the add-on: lori (Life-of-request info 0.2.0.20070425 I found noticed that the problem occur with this add-on too.

I also noticed that the problem is based on the statusbar as I suspected.
As an example. Install the lori add-on.

Use my example file and shrink the browser window while looking at the statusbar.
The div will NOT use min-width because it will stop at the length of the add-on data down in the statusbar. Install even more add-ons that put stuff in the statusbar and the min-width will increase even more. Well, I guess the min-width is used correctly but Firefox won't shrink the actual visible viewport or something.

Comment 12

[Mats Palmgren (inactive)]

Yeah, I think this is a bug.  It doesn't have anything to do with the
CSS min-width you have in the testcase, it's just that the viewport
doesn't shrink as it should.  I can see it without add-ons in SeaMonkey
on the second testcase which stops shrinking at about 300px and clips
the content (without providing a scrollbar).  I guess the problem will
get worse if you add a lot of add-ons which adds stuff to the status bar
or toolbars.
IMO the content viewport should be able to shrink to zero width.

Comment 13

[Johan]

Yes, absolutely. The viewport should indeed be able to shrink down to zero or it would be pointless to used min-width on elements since you can never know what a user has in the statusbar that will restrict the actual area.

Comment 15

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

It's very strange. I tried to test it in my normal profile and in a blank profile. With the normal one max-width is about 310px... with a blank profile, 200px!

Comment 16

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Now I can resize it in a min-width = 200px with the normal profile, but no more with the blank one! And I don't know what it was changed.

Anyway, this bug happens to me also in a blank profile, so I think it's not a bug related to extensions.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008052308 Minefield/3.0pre

It happens to me also with Fx2, but the width is not much wider as in Fx3.

Comment 17

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Ah, I've found! The problem is not statusbar, but the toolbar. If you remove all toolbar items, the div width can be reduced to the minimum size of 100px.

Comment 18

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Attachment: Screenshot: min-width:100px with a large toolbar

This is a screenshot. I think this happens also with a statusbar full of items, of with any other bar.

I think Firefox set documents mix-width at min-width of its GUI components, if it is greater. I don't know if it's an intended behaviour... but if it is, the question is: why?

Comment 19

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Attachment: Screenshot: min-width:100px with without the Fx toolbar

Comment 20

[[e-mail]]

Verified regression, see also bug 366952 comment #12.

Comment 22

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

In Seamonkey Bug 435652 Comment #10 there's a proposed solution that seems to work also for Firefox:

hbox.textbox-input-box {
  overflow-x: hidden;
}

Could it be a valid solution?

I think the correct product/component is Firefox - Theme, I change it.

Comment 24

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: screenshot showing the problem in conjunction with zoom

This bug has an impact on fullZoom's quality and usability : open www.lemonde.fr and change fullZoom factor to 20% (you can use glazoom extension for that). Then slowly decrease the width of the window down to 250px. When the window's width reaches the minimal toolbar's width, the viewport stops shrinking and the position of the zoomed out content gets pinned down... The attached screenshot shows (from left to right) IE8, FF3 and Opera9.23 in the same situation. Clearly, FF3 sucks here.

Comment 25

[Dão Gottwald [:dao]]

Attachment: screenshot, no bug

WFM on trunk.

Comment 26

[Dão Gottwald [:dao]]

As field this bug is a duplicate of bug 312247. Please head over to bug 428939 if there's a new regression.