328040 - Pages refuse to shrink under certain width

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[dolphinling]

Recently, pages have started refusing to shrink under a certain width. If the window is made smaller than this, first the vertical scrollbar, then the page contents will simply be clipped. The width seems to be the minimum width of the navigation toolbar, i.e. back/forward/etc. buttons + URL bar + search box. If the page has a live bookmarks icon or secure site icon it's slightly wider.

Testcase in URL field, simply shrink the browser to see.

Regression range coming

Comment 1

[dolphinling]

Regressed between 2006-02-09 and 2006-02-10

Comment 2

[dolphinling]

Shrinking data: url, bugzilla gives an error every time I make a change and I think that might be the reason.

Comment 3

[[e-mail]]

I see a similar effect in SeaMonkey mail; if I open with both the Location Toolbar and the Search Bar visible then it stretches the rest of the XUL content to their combined width, although if I hide either of the Location Toolbar and the Search Bar then the effect goes away even if I then show them again. Additionally if I show all the buttons on the main mail toolbar so that it should be wider than the Location Toolbar it does not affect the minimum width.

Comment 4

[[e-mail]]

(In reply to comment #2)
>Shrinking data: url, bugzilla gives an error every time I make a change and I think that might be the reason.
Still getting bugzilla errors :-(

Comment 5

[dolphinling]

blocking 1.9a1? This bug shouldn't be in _any_ release build, even an alpha.

Comment 6

[Felix Miata]

Attachment: screenshot

It seems I'm seeing this on the branch: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8) Gecko/20060228 SeaMonkey/1.1a

Comment 7

[James Darpinian]

This bug may not be new, I have seen it in 1.5.  For example, I see a very mild version of it on this bugzilla page; if I make the window as narrow as possible the vertical scroll bar is just barely obscured.

Comment 8

[Ria Klaassen (not reading all bugmail)]

If I understand it well, Bug 312247 is similar or a duplicate.
For Windows, this bug consists of two problems. See also Bug 312247.
The first problem would be solved when the fix of Bug 323839 is checked in.
And the second problem is caused by the fix of Bug 326123.

With some copy & paste work I discovered that the problem would be solved with this userChrome.css:

toolbar {
  min-width: 1px;
}

textarea > .anonymous-div,
input > .anonymous-div {
  padding: 0px;
}

But that would undo the fix of Bug 326123 I think.

Comment 9

[Uri Bernstein]

I'm seeing the same problem on OS X => All/All.

However, the workaround suggested in comment #8 does *not* fix this for me.

I tried putting the "padding: 0px;" part both in userChrome.css (where it didn't undo the fix to  Bug 326123) and in userContent.css (where it did). In both cases I had the toolbar min-width part in userChrome.css, and in both cases I could still see this bug.

Comment 10

[Uri Bernstein]

OK. So I confirmed that bug 326123 indeed caused this, by directly editing forms.css in the application bundle. At the same time, [e-mail] also confirmed this (bug 326123 comment #7).

Still, I can't think of a reason why that change (which shouldn't have affected chrome at all, as far as I can tell), caused this. I'm pretty sure ther's a deeper issue here, which was merely triggered by the patch to 326123.

CCing dbaron, which might have an idea what's going on here.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> which shouldn't have affected chrome at all, as far as I can tell

XUL textboxes have an HTML textbox inside them....

What min and max sizes do things report when you reflow?  My first guess would be that something went from a zero to nonzero min-size (or max-sized) and that XUL layout gets "confused" by this somehow (or rather does exactly what it's designed to do).

Comment 12

[Uri Bernstein]

Attachment: reflow log - before

(In reply to comment #11)
> What min and max sizes do things report when you reflow?

I'm not sure I know how to answer this, but hopefully you'll be able to read it from the reflow logs. This one is without padding on the input element (i.e., before the regression). I'll attach an "after" one soon.

Comment 13

[Uri Bernstein]

Attachment: reflow log - after

Reflow log with the padding. The problem probably manifests itself in the next-to-bottom line, which is here:

 root 0x33c9984 d=7830,1424 

as opposed to:

 root 0x3410384 d=15,15 

before. Also it seems that more is happening here (the log is longer). That's about as much as I can say about this, I'm afraid.

Comment 14

[Uri Bernstein]

OFF TOPIC:

I'm getting a bugmail every day notifying me (again and again) of the last three comments on this bug (including two of my own).
Are other people getting this? Is this a known Bugzilla bug? Is there anything I can do about it?

Comment 15

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #14)
> OFF TOPIC:
> 
> I'm getting a bugmail every day notifying me (again and again) of the last
> three comments on this bug (including two of my own).
> Are other people getting this? Is this a known Bugzilla bug? Is there anything
> I can do about it?

Yes, I'm getting it too (it's quite annoying). Maybe justdave can help figure out what's going on in #bmo.

Comment 16

[Uri Bernstein]

Clearing the URL field, in hope that it was the cause for the Bugzilla errors and repeated bugmail.

Content was:
data:text/html,text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text

Comment 17

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #14)
> OFF TOPIC:
> 
> I'm getting a bugmail every day notifying me (again and again) of the last
> three comments on this bug (including two of my own).
> Are other people getting this? Is this a known Bugzilla bug? Is there anything
> I can do about it?
> 
I see the opposite. In spite of my settings about 20% of all bugmail is not sent to me. I received comments 11-16 only half an hour ago. The last mail is from 20 March.

Comment 18

[Boris Zbarsky [:bzbarsky]]

> I'm not sure I know how to answer this

Breakpoint in nsTextControlFrame::Reflow (since we know that a text control change is what changes things here) and see what values it passes out in its desired size to the parent?  If those are different with and without the patch for bug 326123 (as I suspect they are), then trace through nsTextControlFrame::Reflow looking for the difference...

Comment 19

[Uri Bernstein]

(In reply to comment #18)
> > I'm not sure I know how to answer this
> 
> Breakpoint in nsTextControlFrame::Reflow 

The breakpoint I put in nsTextControlFrame::Reflow was never reached.
I tried breakpointing in nsTextControlFrame::GetPrefSize and nsTextControlFrame::GetMinSize, and found they were returning (2175,195) and (-1,-1) respectively, both with the patch and without it. I'm not sure where to go from here.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Uri, this is with the window narrow enough to reproduce the bug?  2175 sounds awful wide for that....  If so, what were they returning for GetMaxSize?

Comment 21

[Uri Bernstein]

(In reply to comment #20)
> Uri, this is with the window narrow enough to reproduce the bug?  2175 sounds
> awful wide for that....  If so, what were they returning for GetMaxSize?
> 

Checked again. With the patch, these are the values returned regardless of the window size (and whether or not it is narrow enough to reproduce the bug). GetMaxSize returns (UC,UC).

Without the patch, I'm not hitting any of these breakpoints when the window is narrow enough so that I would have seen the bug if the patch was in. When it is wider, I'm getting the same values as before (including the UC,UC for GetMaxSize).

I'll try to investigate what leads to the difference (i.e. why these methods are not reached for narrow widths before the patch), but I'm not sure that will be today.

Comment 22

[Boris Zbarsky [:bzbarsky]]

I think it's worth revisiting this after reflow branch lands.

Comment 23

[Mark Mentovai]

*** Bug 338722 has been marked as a duplicate of this bug. ***

Comment 24

[Boris Zbarsky [:bzbarsky]]

For what it's worth, I don't see this bug on the reflow branch.

Comment 25

[Boris Zbarsky [:bzbarsky]]

*** Bug 346653 has been marked as a duplicate of this bug. ***

Comment 26

[Uri Bernstein]

This WFM in FF trunk with the default theme since 2006-09-22, that is, since the landing of the new theme on Trunk (bug 353673).

Using a different theme, I verified that this was really fixed by the reflow branch landing (bug 300030).

Comment 27

[Boris Zbarsky [:bzbarsky]]

Need regression test...

Comment 28

[[e-mail]]

I'm still seeing this, and comment #8 no longer works as a workaround either.

Comment 29

[Ria Klaassen (not reading all bugmail)]

Bug 346274 could play a role, but I do see a vertical scrollbar.

Comment 30

[Philip Chee]

Currently this works for me for the URL bar in SeaMonkey.

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

But at much smaller widths something else seems to be pushing the contents under the right edge.