331041 - Hang printing table with rowspan and thead

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Eli Friedman]

Testcase coming up; to reproduce, just print/print preview.

Comment 1

[Eli Friedman]

Attachment: Testcase

Comment 2

[Mats Palmgren (inactive)]

Attachment: FWIW, some trace output

See bug 331039 comment 4. This is basically the same thing, the repeated
<thead>'s in this trace is just the auto-created once we create for each
new page, they were not pushed as overflow...

Comment 3

[luca]

In beta 2 the testcase doesn't hang anymore (I suppose by accident, since I see no activity on this bug) but the wikipedia page still hangs.

Comment 4

[Bernd]

we need a new testcase here

Comment 5

[Eli Friedman]

This bug was never associated with the Wikipedia page.  The original page was attachment 208730 [details].  Hmm, guess I didn't notice when the URL field changed.  Changing to correct URL.

Marking "WORKSFORME" based on testing with current trunk build.  Reopen/comment if you can still reproduce a hang with either the reduced testcase or the sanitized page.

Comment 6

[luca]

It isn't fixed, at least in Linux the testcase still hangs (yesterday I just tried in windows).
I suppose that it's "fixed" in windows by accident, not by design. Maybe if you try a different page size/page layout it will hang even in windows, so I don't think this is really fixed.

Comment 7

[Mats Palmgren (inactive)]

Luca, which Linux build did you test - was it a trunk build?
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

I can reproduce the hang in Firefox 2.0b2 on Linux, but not in a current
trunk build.

Comment 8

[luca]

It was beta 2, the trunk doesn't hang. Still, I think it is by accident and not by design (the trunk still hangs on bug 323652).

Comment 9

[Bernd]

The trunk branch difference might be bug 344883.

<offtopic>
Claiming that a bug fix is by accident and not by design is pretty close to be offensive for people (like me) who spent there time on fixing bugs.

If you want to verify what did not go on branch you have to narrow down when the trunk changed and remember the golden rule: "lxr is your friend". Its probably more bonsai in this case.
</offtopic>

Comment 10

[luca]

No offense intended, it's just that there's been no activity on this and especialy bug 323652, and I'm not really confortable with my users still on 1.07 due to these freezes.

Comment 11

[Hermann Schwab]

Reopening as testcase is hanging on Win98, this should be fixed for Firefox2
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b2) Gecko/20060901 BonEcho/2.0b2
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b2) Gecko/20060901
SeaMonkey/1.1b

Comment 12

[Eli Friedman]

Do not reopen bugs based on testing with a branch build!  It's just a waste of time.

If you think it should be fixed for Firefox 2, figure out which trunk patch fixed this and say in that bug that you think that patch should be on the branch for whatever reason you have for saying that.  It probably won't help all that much, but it's the best you can do without being a developer.

Comment 13

[Hermann Schwab]

(In reply to comment #12)
> Do not reopen bugs based on testing with a branch build!  It's just a waste of
> time.
> 
> If you think it should be fixed for Firefox 2, figure out which trunk patch
> fixed this and say in that bug that you think that patch should be on the
> branch for whatever reason you have for saying that.  It probably won't help
> all that much, but it's the best you can do without being a developer.
> 

Should I file a new bug based on branch then? I can't test using trunk, as Win98 got culled. I also can't do regression testing based on trunk nightlies as I used to. If this bug was critical on trunk, is it completely unimportant on branch now?

Comment 14

[Mats Palmgren (inactive)]

I can reproduce this hang in a 1.8 branch debug build on Linux.
Applying the patch in bug 344883 fixes it.

Comment 15

[Eli Friedman]

(In reply to comment #13)
> Should I file a new bug based on branch then? I can't test using trunk, as
> Win98 got culled. I also can't do regression testing based on trunk nightlies
> as I used to. If this bug was critical on trunk, is it completely unimportant
> on branch now?

The status of a bug only reflects its state on the trunk.  Branch state is noted with various other information, like the blocking1.8.1 bug flag, the approval1.8.1 patch flag, and the fixed1.8.1 keyword.

Bugs should not be filed against a branch unless there is not an existing bug and the issue is critical (like a crash bug).

According to comment 14, the patch in bug 344883 fixes this issue.  The patch was checked into the trunk.  Apparently, it is now going through the branch approval process.

Getting a patch into the branch is an additional procedure which occurs in the bug with the patch.  The person who wrote the patch (or occasionally another developer) initiates the process by setting the approval1.8.1 flag to "?".  Ultimately, whether a patch is checked in depends on a benefit vs. risk analysis (risk being that of regressions).