444375 - Table cells not wrapping on web page

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect, P1)

Description

[Kevin goertz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Table cells on this web page wrap correctly on all other browsers including all other versions of Firefox.

Reproducible: Always

Steps to Reproduce:
1.open web page
2.
3.
Actual Results:  
Open web page http://profiler.noaa.gov/npn/npnWindViewer.jsp

Expected Results:  
Profiler icons will be in one long string or accasionally wrap the last two.

In all other browsers including all other Firefox versions the table wraps to the minimized size or full screen size of browser.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Regression range is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1196673660&maxdate=1196674679
-> Bug 368554.

Comment 2

[Ria Klaassen (not reading all bugmail)]

There has been some improvement over time; when I change my font to Verdana, it wraps.

Comment 3

[Martijn Wargers (dead)]

Attachment: testcase

Comment 4

[Martijn Wargers (dead)]

Between every <span> and <img>, there is a tab character.
And for some reason, the font-family: arial needs to be set on the span (not on the body for example), in order for the bug to occur.

Comment 5

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

Not blocking but definitely wanted and should probably block 1.9.1. Roc, who can own this?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Me I guess.

Comment 7

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

Not blocking, but we'd take a patch after it lands on trunk.

Comment 8

[Boris Zbarsky [:bzbarsky]]

The tabs don't seem to be relevant; I get the same behavior with spaces instead.

The font style probably matters because it breaks up the text into one textrun per span.

Comment 9

[Boris Zbarsky [:bzbarsky]]

And it looks like we're not allowing wrapping on that whitespace at the beginning of the textrun for some reason...  Something to do with being followed by a replaced element?

In any case, I think we should fix this for 1.9.1.

Comment 10

[Frédéric Buclin]

Is this bug the same root cause explaining why long lines in patches no longer wrap in diff mode? One example is https://bugzilla.mozilla.org/attachment.cgi?id=335648&action=diff#mozilla/webtools/bugzilla/t/007util.t_sec1

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

This fix was somewhat easier than I feared. When calculating the min-width for the space inside the <span>, we need to allow the code to reach the part where we check for TEXT_HAS_TRAILING_BREAK even when start == flowEndInTextRun. (For the space inside the <span>, start == flowEndInTextRun because the space was collapsed away to nothing.)

The change in AddInlinePrefWidthForFlow is not strictly necessary --- in that method, nothing interesting can happen in the loop over i when start == flowEndInTextRun --- but I'm trying to keep that method in sync with AddInlineMinWidthForFlow.

Comment 12

[Damon Sicore (:damons)]

So, this is marked blocking1.9.1+ and a P1.  Since it's also not targeted at b2 milestone, I want to make sure we're intentionally saying that we do *not* need a beta for this.  

So, does this require a beta vector?

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't think so.

Comment 14

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Landed on mozilla-central (and thus also on mozilla-1.9.1):
http://hg.mozilla.org/mozilla-central/rev/59950d816bf5

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified with:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081213 Shiretoko/3.1b3pre ID:20081213034757

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20081213 Minefield/3.2a1pre