Closed Bug 1621274 Opened 2 years ago Closed 1 year ago

ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file .../mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 758

Categories

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

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
83 Branch
Tracking Status
firefox83 --- fixed

People

(Reporter: ishikawa, Assigned: ishikawa)

References

(Blocks 1 open bug)

Details

Attachments

(5 files)

I set platform as x86_64 and linux (this is my local PC), but I suspect this bug appears on all the platforms

During mochitest run of C-C TB FULL DEBUG version locally, I see many assertions of the following form. 498 times to be exact.:

498: Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 758

Note the number 498 at the beginning of the line. That is added by my script to summarize the errors/warnings.

Now, interestingly another already reported(?) bug appears exactly same number of times.

498: Main Thread] ###!!! ASSERTION: didn't subtract all that we added: '(space == 0 || space == nscoord_MAX) && ((l2t == FLEX_PCT_LARGE) ? (-0.001f < basis.f && basis.f < 0.001f) : (basis.c == 0 || basis.c == nscoord_MAX))', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 983

This is mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=513106#c4

So I believe these two assertions are related.

498 is a bit too many.

We should investigate this.

The assertions can be found in other people's tyrserver runs as well.

For example,

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&fromchange=6c81ea172348b677edd90753b6f5b5be3afbce6a&selectedJob=292189682
https://firefoxci.taskcluster-artifacts.net/FZzfXi8FScuJpukxLvuuBA/0/public/logs/live_backing.log

You will notice that

"Table inline-size ..." assertion precedes "didn't subtract all that ..." assertion. They appear in pairs.

Does this happen only on thunderbird? It's likely that this is an interaction between XUL and table layout that we probably don't want to spend resources fixing then.

Priority: -- → P3

But if you come up with a test-case that reproduces it let me know and I'm happy to poke a bit.

Attached patch 1621274.patchSplinter Review

This is a patch to print relevant values when the error occurs.

This is a dump of the relevant values when an assertion was triggered.
Simply invoking DEBUG version of C-C TB causes the assertion.
The value dump is done by local mod by this patch.

{debug}:ASSERTION aISizeType=2, BTLS_FINALSIZE=2
aISize=0, guess_min=13764, guess_pref=13764
[3934, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
{debug}:ASSERTION
space=-13764, nscoord_MAX=1073741823
l2t=0, FLEX_PCT_LARGE=6
basis.c=0, nscoord_MAX=1073741823, basis.f=0.000000
[3934, Main Thread] ###!!! ASSERTION: didn't subtract all that we added: '(space == 0 || space == nscoord_MAX) && ((l2t == FLEX_PCT_LARGE) ? (-0.001f < basis.f && basis.f < 0.001f) : (basis.c == 0 || basis.c == nscoord_MAX))', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 1004
{debug}:ASSERTION aISizeType=2, BTLS_FINALSIZE=2
aISize=0, guess_min=13764, guess_pref=13764
[3934, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
{debug}:ASSERTION
space=-13764, nscoord_MAX=1073741823
l2t=0, FLEX_PCT_LARGE=6

The line number got shifted a bit due to the dump statement.

Are we sure if the assert condition on the line
https://searchfox.org/comm-central/source/mozilla/layout/tables/BasicTableLayoutStrategy.cpp#758
correct?

I mean, the condition is negated in NS_ASSERTION(). Is it intended ?

if (aISize < guess_pref) {
    if (aISizeType != BTLS_FINAL_ISIZE && aISize <= guess_min) {
      // Return early -- we don't have any extra space to distribute.
      return;
    }
    NS_ASSERTION(!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min),   <===
                 "Table inline-size is less than the "
                 "sum of its columns' min inline-sizes");
    if (aISize < guess_min_pct) {

As for the other dump, space=-13764 certainly looks suspicious.

space=-13764, nscoord_MAX=1073741823
l2t=0, FLEX_PCT_LARGE=6
basis.c=0, nscoord_MAX=1073741823, basis.f=0.000000

https://searchfox.org/comm-central/source/mozilla/layout/tables/BasicTableLayoutStrategy.cpp#983

  NS_ASSERTION(
      (space == 0 || space == nscoord_MAX) &&
          ((l2t == FLEX_PCT_LARGE) ? (-0.001f < basis.f && basis.f < 0.001f)
                                   : (basis.c == 0 || basis.c == nscoord_MAX)),
      "didn't subtract all that we added");
Assignee: nobody → ishikawa

The number of assertions from mochitest of FULL DEBUG version of TB in the latest M-C/C-C tree seems to have dwindled to 182. (Not sure why the number has decreased.)

In mochitest, I see TEST_START, TEST_END and "Entering test" markers so that I list the ASSERTIONS by the following command to show the relative positions of where they occur in the test framework.

egrep  "(TEST_START|TEST_END|Entering test|ASSERTION: Table inline-size)" log1203-mochitest-fixedstack.txt

log1203-mochitest-fixedstack.txt is my local log file.

From the list in the attachment, you can see that the assertion occurs when no test seems to be in place.

... omission ...
 0:03.76 TEST_START: comm/mail/test/static/browser_parsable_css.js
 0:03.76 TEST_END: SKIP
 0:03.76 TEST_START: comm/mail/test/static/browser_parsable_script.js
 0:03.76 TEST_END: SKIP
 0:21.30 GECKO(727384) [727384, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
 0:28.94 TEST_START: comm/calendar/test/browser/browser_basicFunctionality.js
 0:31.41 INFO Entering test bound testBasicFunctionality
 0:32.38 GECKO(727384) [727384, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
 0:34.08 GECKO(727384) [727384, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
...

GEKO(727384) process was started a dozen seconds or so before the ASSERTION.

 0:04.94 INFO Application command: /NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/thunderbird -marionette -foreground -profile /COMM-CENTRAL/TMP-DIR/tmpVc7ZqM.mozrunner
 0:04.96 INFO runtests.py | Application pid: 727384
 0:04.96 Started process `GECKO(727384)`

This fits my observation that the ASSERTION occurs by merely starting thunderbird.

I would suggest if someone can dig deeper in the issue, please try
the first two tests of mochitest (and subsequent calendar tests.)

 comm/calendar/test/browser/browser_basicFunctionality.js
 comm/calendar/test/browser/browser_calendarList.js

This I say because the first couple of tests seem to get stuck (no screen change for a long time after an initial screen is created.
Yes, I show the test window on my display while the test runs. The seemingly stuck state is quite obvious because nothing happens while, at other times, the screen is redrawn incessantly.
Something IS very wrong when the assertion is hit in these tests.

 0:28.94 TEST_START: comm/calendar/test/browser/browser_basicFunctionality.js
 0:31.41 INFO Entering test bound testBasicFunctionality
 0:32.38 GECKO(727384) [727384, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
 0:34.08 GECKO(727384) [727384, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
 0:34.54 GECKO(727384) [727384, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
 0:34.63 GECKO(727384) [727384, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
 0:35.39 TEST_END: Test OK. Subtests passed 5/6. Unexpected 0
 0:35.47 TEST_START: comm/calendar/test/browser/browser_calendarList.js
 0:35.48 INFO Entering test bound
 0:36.89 GECKO(727384) [727384, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
 0:45.01 GECKO(727384) [727384, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
 0:45.28 TEST_END: Test OK. Subtests passed 139/140. Unexpected 0
 0:45.28 TEST_START: comm/calendar/test/browser/browser_eventDisplay.js
 0:45.41 GECKO(727384) [727384, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
 0:46.14 GECKO(727384) [727384, Main Thread] ###!!! ASSERTION: Table inline-size is less than the sum of its columns' min inline-sizes: '!(aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min)', file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line 767
 0:46.80 INFO Entering test bound testInsideDayView

Emilio, you mentioned that:
"Does this happen only on thunderbird? It's likely that this is an interaction between XUL and table layout that we probably don't want to spend resources fixing then."
Is this still the case? I mean, XUL is being removed and I have a feeling that a lot has been removed already. No? If so, the problem is a permanent fixture which we should get rid of.
But I am not familiar with XUL removal status myself.

Flags: needinfo?(emilio)

Is this still the case? I mean, XUL is being removed and I have a feeling that a lot has been removed already. No? If so, the problem is a permanent fixture which we should get rid of.

There's still a lot of XUL layout code in use both in Firefox and Thunderbird. So yes, I suspect this is still the case.

Do you have a stack for that assertion? I should be able to tell really fast if it is inside XUL layout code.

Flags: needinfo?(emilio)

Thank you for your comment.

Attached is excerpt of several ASSERTs near the beginning of local mochitest with FULL DEBUG version of TB.

One thing I noticed. I wanted to see if the stacks are the same or not and compared them.
There are two variants.

Note there are similar stack backtraces.
Say, starting with #01: nsTableFrame:GetColumnISizeFromFirstInFlow
The look very similar.
However, I noticed there are two variants.

If you compare the stack in detail, you will notice that at #21 frame, one variant has

 #21: void PaintMaskAndClipPathInternal<nsSVGIntegrationUtils::PaintMaskAndClipPath(nsSVGIntegrationUtils::PaintFramesParams const&)::{lambda()#1}>(nsSVGIntegrationUtils::PaintFramesParams const&, nsSVGIntegrationUtils::PaintMaskAndClipPath(nsSVGIntegrationUtils::PaintFramesParams const&)::{lambda()#1} const&) (/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/gfx/Matrix.h:46)

and the other variant has

#21: nsSVGUtils::GetRelativeRect(unsigned short, mozilla::SVGAnimatedLength const*, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits, double> const&, nsIFrame*) (/NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/svg/nsSVGUtils.cpp:1168)

From #01: nsTableFrame::...
to #20: void PaintMaskAndClipPathInternal,
they are the same.

Those stacks make no sense, they are pretty busted. Those call stacks just cannot happen from the code.

mozilla::dom::IDBDatabase_Binding::Wrap cannot call `Element_Binding::before and so on. Something is off with those stacks.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)

Those stacks make no sense, they are pretty busted. Those call stacks just cannot happen from the code.

mozilla::dom::IDBDatabase_Binding::Wrap cannot call `Element_Binding::before and so on. Something is off with those stacks.

I have a problem with the newly introduced fix-stacks program. I will see what I can do to fix it...
Oh, wait.
I think you can take a peek at other people's tryserver runs (I have not been able to run tryserver run for the last few weeks.: I am not sure if my patch in M-C portion is to blame.)

For example, you can see the stack trace in
the following live.log of Geoff's try run:
https://firefoxci.taskcluster-artifacts.net/YW5CEleXTtSX5whyJbC5mw/0/public/logs/live_backing.log

It looks they are from XULLayout() ...

Yeah, so this is exactly a table-inside-xul case.

In this case, then, I may want to change the ASSERT into a simple print out or something.
It causes great slow down during mochitest run (more so when TB is run under valgrind to test for memory-related errors.)

Would it be OK to post such a patch in this bugzilla or should I file a separate bugzilla?

It'd be ok at either place, but it would be nice to keep it as an ASSERT when XUL is not involved.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)

It'd be ok at either place, but it would be nice to keep it as an ASSERT when XUL is not involved.

Hmm. There are two approaches to make this happen.

  1. Static knowledge and transition.
    We will know when XUL is removed. Then turn the printing to ASSERT(). Manual.
    Somebody has to turn it back to ASSERT.
    Until that happens, a buggy call to the function in question will only print the warning/error.

  2. Dynamic check of stack (!)
    When the assert condition is observed, we check the stack and see if this is a desendent of XULLayout call chain, we will only print the conditin. Otherwise, we will print the full stack dump.
    More reliable than approach 1.
    However, the processing complexity is basically the same as the current ASSERT stack dump. Hmm.

I might as well simply replace the ASSERT() with a simple print locally.
With about 240 such similar asserts, I think the bug is adding about a 2-3 minutes to the whole mochitest run. It is not that big in comparison to the whole mochitest elapsed time. But I suspect that the workload on tryserver adds up.

Let me think what I am going to do about this.

I was thinking you should just check GetParent()->IsXULBoxFrame(), not do stack walking or anything.

I see. That sounds easy and reasonable.
Let me check if that approach goes anywhere.

Thank you for the tips.

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Assignee: ishikawa → nobody
Severity: normal → S3

I have been posting TB patches and I am not familiar with phabricator (and I have tough time to load some kind of authenticator on my smartphone which is company-supplied at this moment. The phabricator guide I was suggested mention this two-factor authentication.).

Anyway, here is the patch I have created based on the suggestion on comment 13.

It works locally, and it works on TryServer (sorry it is part of the TB compilation, but I did modify the M-C portion of the tree for this bugzilla.)
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=58cbea138b134aae4a94842a8f8f3e29bd693e7b

So what do I do? I can try to install the 2-factor authenticator on my smartphne or if somebody can pick it up from here, it will be fine with me.
With the patch, instead of printing the whole stackdump, it prints something like the following.

48:38.21 GECKO(814918) {debug}:ASSERTION: ! (aISizeType == BTLS_FINAL_ISIZE && aISize < guess_min), /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line=762
48:38.21 GECKO(814918) aISizeType=2, BTLS_FINALSIZE=2
48:38.21 GECKO(814918) aISize=0, guess_min=10203, guess_pref=10203
48:38.21 GECKO(814918) parent at the position [2] is XULBox.
48:38.21 GECKO(814918) {debug} This strange situation is with XULBox Frame. Just ignore it for now.
48:38.21 GECKO(814918) {debug}:ASSERTION: (space == 0 || space == nscoord_MAX) && ((l2t == FLEX_PCT_LARGE) ? (-0.001f < basis.f && basis.f < 0.001f) : (basis.c == 0 || basis.c == nscoord_MAX)), /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/tables/BasicTableLayoutStrategy.cpp, line=1023
48:38.21 GECKO(814918) space=-10203, nscoord_MAX=1073741823
48:38.21 GECKO(814918) l2t=0, FLEX_PCT_LARGE=6
48:38.21 GECKO(814918) basis.c=0, nscoord_MAX=1073741823, basis.f=0.000000
48:38.21 GECKO(814918) parent at the position [2] is XULBox.
48:38.21 GECKO(814918) {debug} This strange situation is with XULBox Frame. Just ignore it for now.

Assignee: nobody → ishikawa
Flags: needinfo?(emilio)

That patch is way too complicated than what it should be, fwiw. I'll post a revised version.

Also, is there any chance that Thunderbird could move those elements away from XUL layout? You can see which elements they are using frame->GetContent()->List() or frame->DumpFrameTreeLimited().

Flags: needinfo?(emilio)

Realistically we're not going to bother investigating these, I suspect,
and Thunderbird seems to hit these too often in their tests.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #17)

That patch is way too complicated than what it should be, fwiw. I'll post a revised version.

Thank you for your simplified patch. (I was not sure if there is anyone interested in the values that cause the assertion to hit. Just in case, I dumped them.)

Also, is there any chance that Thunderbird could move those elements away from XUL layout? You can see which elements they are using frame->GetContent()->List() or frame->DumpFrameTreeLimited().

I have no idea. Someone in the know needs to look at the issue.
Calendar code seems to be hit by the assertions most since it deals with tables basically.

I just wanted to clean up the mochitest log as much as possible to see if my planned patches cause regressions. At the current state of many JavaScript errors and assertions, it is tough to figure out if my patch is causing additional problems or simply the tests are not performing well in the first place.

Thank you again for your suggestion to avoid stack dump if the issue is related to XULBox.
My local mochitest log size has shrunk from 20.5 MiB to 18.5 MiB. (There may be other cleanups, but I think the reduction by this patch contributed most.)

Come to think of it, I think I should file a bugzilla concerning this so that, even though the assertion disappears now, TB developers are aware of the issue.

Also, is there any chance that Thunderbird could move those elements away from XUL layout? You can see which elements they are using >
frame->GetContent()->List() or frame->DumpFrameTreeLimited().

Blocks: 1638591

Our goal is to remove XUL layout ASAP. The solution to this bug is for TB to stop using XUL and instead use CSS display types.
I think this bug should be resolved as WONTFIX. "Fixing" minor issues like this in DEBUG builds is simply not a problem we should expend any resources on whatsoever. It's counterproductive since we could have spent this time on bugs that matter instead. :-(

(In reply to Mats Palmgren (PTO) from comment #21)

Our goal is to remove XUL layout ASAP. The solution to this bug is for TB to stop using XUL and instead use CSS display types.
I think this bug should be resolved as WONTFIX. "Fixing" minor issues like this in DEBUG builds is simply not a problem we should expend any resources on whatsoever. It's counterproductive since we could have spent this time on bugs that matter instead. :-(

Can we simply add the patch to the M-C tree?
The patch here is simply suppress the stacktrace for known XULBox case, and it is already shown to work.

The sheer amount of stack trace from the assert adds almost 2MB to debug log (dwindled somewhat lately) and really is a pain to wade through and makes it difficult to analyze the bugs that matter. The patch eliminates the stack trace.

So what should I to push the patch to be adopted to M-C tree?

Elimination of XUL usage here in this particular case is filed in bug 1638591.
(Of course, Usage of CSS in general is handled somewhere else, but I don't know the exact bugzilla number.)

(In reply to ISHIKAWA, Chiaki from comment #22)

The sheer amount of stack trace from the assert adds almost 2MB to debug log (dwindled somewhat lately) and really is a pain to wade through and makes it difficult to analyze the bugs that matter. The patch eliminates the stack trace.

What I mean by I say "a pain to wade through and makes it difficult to analyze the bugs that matter" can be observed by taking a look at
the log file on tryserver.

Please take a look at recent try-comm-server jobs such as https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=5838f17245a428a2564e55241021ffcbb9be7042 (that is someone else's job) and look at mochitest log, say, https://firefoxci.taskcluster-artifacts.net/dAUd1LEvSXyqe173rSgQBQ/0/public/logs/live_backing.log
There are simply too many such stack dumps.
(Ouch, I don't know why the stack trace is undecoded. There seems to be a bug with fix-stacks setup on try-c-c.)

Given the tendency of mochitest framework to report tests as passing even when there are valid JavaScript syntax errors and other runtime errors that do not finish the tests completely/throughly, we really need to check the test log carefully and the sheer amount of the stacktrace in mochitest is a hinderance.

TIA

(In reply to Emilio Cobos Álvarez (:emilio) from comment #18)

Created attachment 9149625 [details]
Bug 1621274 - Skip some table layout assertions when xul is involved. r=mats

Realistically we're not going to bother investigating these, I suspect,
and Thunderbird seems to hit these too often in their tests.

Emilio,

How can I have this patch of yours land in M-C tree?
Can you propose it to be landed?.

I am familiar with C-C patch, but this has to land in M-C portion and so I am not sure.

TIA

(The dump really pollutes the debug log too much.
See for example, today's submission from someone else.
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=8c903ef8a06a2dfcbb64d4ce7fe1666adc0947ea
The log:
https://firefoxci.taskcluster-artifacts.net/U-OqL-bgRYef9hL4fNFUrA/0/public/logs/live_backing.log )

Flags: needinfo?(emilio)

I requested review. But generally you should remove the table-inside-xul usage, ideally by removing XUL :)

Flags: needinfo?(emilio)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #26)

I requested review. But generally you should remove the table-inside-xul usage, ideally by removing XUL :)

I certainly understand the desire to remove XUL, but TB lacks the man-power to do it quickly.

In the meantime, the log I mention is full of lengthy stackdump (maybe around 60 stackframes deep) and become very lengthy because the assertion is hit so many times.: Also the function names in the stacktrace often get in the way for searching something in the log. :-(

Thank you for requesting the review.

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e726d9e85f7d
Skip some table layout assertions when xul is involved. r=dholbert
Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a92c1b99f57f
Skip some table layout assertions when xul is involved. r=dholbert
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

(In reply to ISHIKAWA, Chiaki from comment #31)

Oh, I see one condition was missing (|| ...).

Not really, I just had to tweak the expected assertion count from an existing crashtest.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #33)

(In reply to ISHIKAWA, Chiaki from comment #31)

Oh, I see one condition was missing (|| ...).

Not really, I just had to tweak the expected assertion count from an existing crashtest.

Oh. Thank you for taking care of the patch.

You need to log in before you can comment on or make changes to this bug.