Closed Bug 1102175 Opened 10 years ago Closed 5 years ago

<body> with writing-mode: vertical-rl doesn't align children to the right

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla71
Tracking Flags:
Tracking Status
firefox71 --- fixed

People

(Reporter: smontagu, Assigned: TYLin)

References

(Blocks 2 open bugs)

Details

(Keywords: css3, intl, testcase, Whiteboard: [leave open], [wptsync upstream])

Attachments

(9 files, 1 obsolete file)

Testcase
(deleted), text/html
Details
test case demonstrating the same problem (perhaps)
(deleted), text/html
Details
When the root element has writing-mode:vertical-rl, make its contents flush right instead of left
(deleted), patch
smontagu
: review-
Details | Diff | Splinter Review
Reftest
(deleted), patch
jfkthame
: review+
Details | Diff | Splinter Review
Propagate writing-mode and direction properties from <body>
(deleted), patch
Details | Diff | Splinter Review
Bug 1102175 Part 1 - Propagate used writing-mode from body element to its ancestors.
(deleted), text/x-phabricator-request
Details
Bug 1102175 Part 2 - Modify the reference file for 817406-4.html, and update test expectations.
(deleted), text/x-phabricator-request
Details
Bug 1102175 Part 3 - Add reftests for altering <body> dynamically.
(deleted), text/x-phabricator-request
Details
Bug 1102175 Part 4 - Add BFC bits to a block if its used writing-mode is different from the parent's.
(deleted), text/x-phabricator-request
Details
Attached file Testcase (deleted) —
When the testcase has writing-mode vertical-rl, the children should be aligned to the right edge of the viewport, as they are in Chrome and IE. This works as expected if writing-mode is set on a wrapper div with width and height 100%, but not when it's set on the <body> element. The testcase also shows a second bug: the <hr> appears as a single dot in vertical modes, instead of a vertical rule.
(In reply to Simon Montagu :smontagu from comment #0) > The testcase also shows a second bug: the <hr> appears as a single dot in > vertical modes, instead of a vertical rule. This is a direct result of how it's defined in html.css; we need to figure out how to adapt this for vertical modes: http://hg.mozilla.org/mozilla-central/annotate/d1adecc7adad/layout/style/html.css#l602 We should tackle that in a separate bug, though.
I filed bug 1102177 for the <hr> issue
The <body> issue here is related to the fact that Gecko and Webkit handle the sizing of the <body> element differently. Try data:text/html,<body style="border:1px solid red">body in Gecko, and note that the size of the <body>, as shown by its border, is just sufficient for its contents. On the other hand, the same testcase in Safari shows that its <body> is the full size of the browser window.
Hmm, further note: the <body> sizing discrepancy noted above is specific to quirks mode. Trying data:text/html,<!DOCTYPE html><html style="border:1px solid blue"><body style="border:1px solid green">body we see the same result in both Firefox and Safari. Nevertheless, with (-webkit-)writing-mode:vertical-rl applied to the <body>, Safari still right-aligns it, even though its block-size is only just enough to contain its contents.
Does Safari do similar things at a change of writing direction when the change isn't from html to body (e.g., when it's just two nested divs, with the outer being horizontal and having extra space and the inner being vertical)?
(In reply to David Baron [:dbaron] (UTC-8) (needinfo? for questions) from comment #5) > Does Safari do similar things at a change of writing direction when the > change isn't from html to body (e.g., when it's just two nested divs, with > the outer being horizontal and having extra space and the inner being > vertical)? No, in this case the inner (vertical-rl) div remains flush left within its (horizontal, wider) container. The html/body case appears to be special. One possibly-relevant thing I notice here is that the computedStyle of the <html> element has "-webkit-writing-mode: vertical-rl", apparently "upwards inheriting" this from its <body> child.
(In reply to Jonathan Kew (:jfkthame) from comment #6) > (In reply to David Baron [:dbaron] (UTC-8) (needinfo? for questions) from > comment #5) > > Does Safari do similar things at a change of writing direction when the > > change isn't from html to body (e.g., when it's just two nested divs, with > > the outer being horizontal and having extra space and the inner being > > vertical)? > > No, in this case the inner (vertical-rl) div remains flush left within its > (horizontal, wider) container. Other browsers seem to be consistent about this, but I have my doubts: in the parallel case of two nested divs where the outer has dir="ltr" and the inner dir="rtl", the inner div is flush *right* in its container, and I would have expected the same to be true with a nested vertical-rl div in a horizontal container.
(In reply to Simon Montagu :smontagu from comment #7) > in > the parallel case of two nested divs where the outer has dir="ltr" and the > inner dir="rtl", the inner div is flush *right* in its container Are you sure? That's not what I see (or expect). Note that the inner div's default (initial) value for "width" is "auto", in which case it will occupy the full width available within its container, and then its *contents* will indeed be flush right by default. But if you explicitly give the inner div a smaller width, you'll see that it stays flush *left* in its containing div, while its contents remain flush *right* inside it: data:text/html, <div dir="ltr" style="border:1px solid blue; width:200px"> <div dir="rtl" style="border:1px solid red; width:100px">test
Poking around in the frame tree to see where we might handle this, I've come up with this patch, which seems to give the desired behavior if writing-mode:vertical-rl is set on the root <html> element, but not if it is only set on <body>. Is this a sensible starting-point, and do we then also want to copy the Safari behavior of propagating the writing-mode upwards from <body> to the root (or should we tell authors they should be setting it on the root themselves if that's what they want)? Comments and suggestions welcome...
Attachment #8531012 - Flags: feedback?(dbaron)
Test ---- http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/wm-block-flow-direction-002.xht Expected result --------------- http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/wm-block-flow-direction-002-ref.xht Notes ----- - Chrome 39.0.2171.71 passes this test. - Firefox 37.0a1 buildID 20141202213750 fails this test. - There are other tests that fail because of this bug
I think Component for this bug should be "Layout: Block and Inline" instead of "Layout: Text". And Version should be "Trunk". Just my opinion here.
Keywords: css3, intl, testcase
Comment on attachment 8531012 [details] [diff] [review] When the root element has writing-mode:vertical-rl, make its contents flush right instead of left This seems like a reasonable start, but I think we probably do want to propagate from body (and a helper function to do so, as I suggested in bug 1071098 comment 16).
Attachment #8531012 - Flags: feedback?(dbaron) → feedback+
Component: Layout: Text → Layout: Block and Inline
This doesn't address the propagation of vertical-rl mode from <body> up to the root, but it does fix the rendering when the writing mode is set on the root itself; I think we want this, regardless of how we tackle the body-to-root issue.
Attachment #8535490 - Flags: review?(smontagu)
Attachment #8531012 - Attachment is obsolete: true
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Blocks: 1108067
The issue of "propagation of vertical-rl mode from <body> up to the root" is a distinct, separate issue. The spec is saying "the writing-mode property of the HTML BODY element is not propagated to the viewport." while on the other hand "the direction property of the HTML BODY element is not propagated to the viewport." is a statement being reconsidered Re: [css-writing-modes][CSS21] propagation of 'direction' from <body> (was Re: [CSSWG] Minutes Telecon 2014-07-09) http://lists.w3.org/Archives/Public/www-style/2014Dec/0003.html Implementors are converging interoperably toward propagating 'direction' and 'writing-mode' from body to viewport (or ICB); so issue 239 should be reopened and resolved accordingly By the way, I take no credit and no merit for mentioning this: Elika found out about or remembered this and told me about it. > but it does fix the rendering when the writing mode is set on the > root itself; I think we want this, regardless of how we tackle the > body-to-root issue. I think you had no choice (to want or not to want this) since "The principal writing mode of the document is determined by the writing-mode and direction values specified on the root element." Gérard
Comment on attachment 8535490 [details] [diff] [review] When the root element has writing-mode:vertical-rl, make its contents flush right instead of left Review of attachment 8535490 [details] [diff] [review]: ----------------------------------------------------------------- I'd rather address this as part of the logicalization of ReflowChild and ApplyRelativePositioning (bug 1079154)
Attachment #8535490 - Flags: review?(smontagu) → review-
Attached patch Reftest (deleted) — — Splinter Review
This includes 2 versions of attachment 8525944 [details]: one with writing mode set on <body>, marked as failing for now, and one with writing mode set on <html>. I tried to make a reftest from http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/wm-block-flow-direction-002-root.xht as well, but although it seems to pass with the naked eye with the patches from bug 1079154, it's a long way from pixel perfect, so I need to look at that more deeply.
Attachment #8538633 - Flags: review?(jfkthame)
Depends on: 1079154
Attachment #8538633 - Flags: review?(jfkthame) → review+
Reduced and specific test with root element having 'writing-mode: vertical-rl': http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s31-block-flow-direction-025.xht Reference file: http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s31-block-flow-direction-025-ref.xht Notes ----- - I am using Linux 3.16.0-28-generic x86_64, KDE 4.14.1, Kubuntu 14.10 utopic, Qt 4.8.6 - Chrome 39.0.2171.95 and IE11 pass this test - Firefox 37.0a1 buildID 20141215131330 fails this test - The blue square unexpectedly disappears (!) in Firefox 37.0a1 buildID = 20141215131330 when window viewport (window.innerWidth) is resized, shrunk to 825px.
Checked in attachment 8538633 [details] [diff] [review] since it passes after the checkins from bug 1079154, but leaving this open for the writing-mode on <body> case (or would it be better to close this and open a new bug for that?). https://hg.mozilla.org/integration/mozilla-inbound/rev/c8270944ab91
Flags: in-testsuite+
Whiteboard: [leave open]
When ICB's 'writing-mode' is 'vertical-rl', then 'right' offset value should win, should have precedence over 'left' offset value in case of an overconstrained scenario. There is nothing specifically saying such in the Writing Modes spec but, intuitively speaking, this would make sense and developers over at Chromium project think so too. So, this test http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/abs-overconstrained-writing-mode.html fails in Firefox 40.0a1 buildID=20150430100104 but passes in Chrome 40+ and in IE11. This test is definitely an edge case; I can file a separate bug report for such single test if requested.
(In reply to Gérard Talbot from comment #23) > http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/abs- > overconstrained-writing-mode.html This testcase is part of position:absolute support, and will be fixed by bug 1079151.
Blocks: 1260054
24 tests testing systematically combinations of conflicting body writing-mode and document root writing-mode values: http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-002.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-003.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-004.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-005.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-006.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-007.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-008.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-009.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-010.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-011.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-012.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-013.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-014.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-015.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-016.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-017.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-018.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-019.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-020.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-021.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-022.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-023.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-024.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-025.xht Reference files for those 24 tests: http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-003-ref.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s31-block-flow-direction-025-ref.xht http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s8-wm-propagation-body-005-ref.xht - - - - - - - Only 5 tests have been submitted to the CSSWG test repository.

FWIW, here is patch to simply propagate relevant properties from body, and a try with this patch; https://treeherder.mozilla.org/#/jobs?repo=try&revision=ab5e1e6fcc97a1c79badb5cd41f7bd3623e14fef

As you can see, some of tests start passing with the change, but a lot of test cases for shape-outside start failing, I guess the tests for shape-outside are something wrong.

As for test cases in css-writing-modes, there are still two failures;

  • normal-flow-overconstrained-vlr-005.xht
  • normal-flow-overconstrained-vrl-004.xht

I haven't looked at them.

Depends on: 1579295
Blocks: 1580385

In 817406-4.html, <body style="direction: rtl;"> needs to propagate up
to <html>, so we should compare its result to 817406-1-ref.html.

Depends on D45481

Attachment #9092181 - Attachment description: Bug 1102175 Part 3 - Add a reftest for changing writing-mode on body dynamically. → Bug 1102175 Part 3 - Add reftests for altering <body> dynamically.

Without this patch, the CHECK_BLOCK_AND_LINE_DIR soft assertion in
nsFloatManager can be triggered with
wm-propagation-body-dynamic-change-002.html added in Part 3.

Add the test as a crashtest because web-platform reftest doesn't seem to
catch our soft assertions.

Depends on D45580

Assignee: jfkthame → aethanyc
Depends on: 1582224

My lastest try run shows that my patch stack fails a11y accessible/tests/mochitest/treeupdate/test_delayed_removal.html which was modified yesterday in bug 1580292. Need te figure out why.

Attachment #9092789 - Attachment description: Bug 1102175 Part 4 - Add BFC bits to a block if its used mWritingMode is different from the parent's. → Bug 1102175 Part 4 - Add BFC bits to a block if its used writing-mode is different from the parent's.
Depends on: 1582619
Blocks: 1587624
Pushed by aethanyc@gmail.com: https://hg.mozilla.org/integration/autoland/rev/50b041e06f23 Part 1 - Propagate used writing-mode from body element to its ancestors. r=jfkthame https://hg.mozilla.org/integration/autoland/rev/2ac28b335c3c Part 2 - Modify the reference file for 817406-4.html, and update test expectations. r=jfkthame https://hg.mozilla.org/integration/autoland/rev/004a0cb8af9f Part 3 - Add reftests for altering <body> dynamically. r=jfkthame https://hg.mozilla.org/integration/autoland/rev/33914610f60f Part 4 - Add BFC bits to a block if its used writing-mode is different from the parent's. r=jfkthame
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/19608 for changes under testing/web-platform/tests
Whiteboard: [leave open] → [leave open], [wptsync upstream]
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Blocks: 1587645

Backed out 4 changesets (bug 1102175) for Android reftest failures at font-inflation-1a.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/c4dedd2d757cca0313d4e25c64169e48173774d2

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&revision=33914610f60fe825ae321a774e32bd9933ff5fc6&selectedJob=270615763

Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=270615763&repo=autoland&lineNumber=36982

Log snippet:

[task 2019-10-10T03:58:06.399Z] 03:58:06 INFO - REFTEST TEST-START | http://10.0.2.2:8854/tests/layout/reftests/writing-mode/font-inflation-1a.html == http://10.0.2.2:8854/tests/layout/reftests/writing-mode/font-inflation-1-ref.html
[task 2019-10-10T03:58:06.399Z] 03:58:06 INFO - REFTEST INFO | SET PREFERENCE pref(font.size.inflation.emPerLine,15)
[task 2019-10-10T03:58:06.399Z] 03:58:06 INFO - REFTEST INFO | SET PREFERENCE pref(font.size.inflation.forceEnabled,true)
[task 2019-10-10T03:58:06.399Z] 03:58:06 INFO - REFTEST INFO | SET PREFERENCE pref(font.size.inflation.lineThreshold,0)
[task 2019-10-10T03:58:06.400Z] 03:58:06 INFO - REFTEST TEST-LOAD | http://10.0.2.2:8854/tests/layout/reftests/writing-mode/font-inflation-1a.html | 7338 / 7932 (92%)
[task 2019-10-10T04:04:52.716Z] 04:04:52 INFO - wait for org.mozilla.geckoview.test complete; top activity=org.mozilla.geckoview.test
[task 2019-10-10T04:04:52.819Z] 04:04:52 INFO - org.mozilla.geckoview.test unexpectedly found running. Killing...
[task 2019-10-10T04:04:52.819Z] 04:04:52 INFO - REFTEST TEST-INFO | started process screentopng
[task 2019-10-10T04:04:53.099Z] 04:04:53 INFO - REFTEST TEST-INFO | screentopng: exit 0
[task 2019-10-10T04:05:07.434Z] 04:05:07 WARNING - TEST-UNEXPECTED-FAIL | http://10.0.2.2:8854/tests/layout/reftests/writing-mode/font-inflation-1a.html == http://10.0.2.2:8854/tests/layout/reftests/writing-mode/font-inflation-1-ref.html | application timed out after 370 seconds with no output
[task 2019-10-10T04:05:07.434Z] 04:05:07 INFO - remoteautomation.py | Application ran for: 0:49:08.725191
[task 2019-10-10T04:05:08.085Z] 04:05:08 INFO - REFTEST INFO | Copy/paste: /builds/worker/workspace/build/linux64-minidump_stackwalk /tmp/tmpc5Z5DO/779bf472-7246-c3e4-5f52-344fbc525d5b.dmp /builds/worker/workspace/build/symbols
[task 2019-10-10T04:05:11.600Z] 04:05:11 INFO - REFTEST INFO | Saved minidump as /builds/worker/workspace/build/blobber_upload_dir/779bf472-7246-c3e4-5f52-344fbc525d5b.dmp
[task 2019-10-10T04:05:11.601Z] 04:05:11 INFO - REFTEST INFO | Saved app info as /builds/worker/workspace/build/blobber_upload_dir/779bf472-7246-c3e4-5f52-344fbc525d5b.extra
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - REFTEST PROCESS-CRASH | http://10.0.2.2:8854/tests/layout/reftests/writing-mode/font-inflation-1a.html == http://10.0.2.2:8854/tests/layout/reftests/writing-mode/font-inflation-1-ref.html | application crashed [@ nsFontInflationData::FindFontInflationDataFor(nsIFrame const*)]
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - Crash dump filename: /tmp/tmpc5Z5DO/779bf472-7246-c3e4-5f52-344fbc525d5b.dmp
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - Operating system: Android
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - 0.0.0 Linux 3.10.0+ #260 SMP PREEMPT Fri May 19 12:48:14 PDT 2017 x86_64
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - CPU: amd64
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - family 6 model 6 stepping 3
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - 4 CPUs
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - GPU: UNKNOWN
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - Crash reason: SIGSEGV /SEGV_MAPERR
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - Crash address: 0x0
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - Process uptime: not available
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - Thread 11 (crashed)
[task 2019-10-10T04:05:11.604Z] 04:05:11 INFO - 0 libxul.so!nsFontInflationData::FindFontInflationDataFor(nsIFrame const*) [nsFontInflationData.cpp:33914610f60fe825ae321a774e32bd9933ff5fc6 : 31 + 0x27]
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - rax = 0x000077d90ea4bdbe rdx = 0x0000000000000001
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - rcx = 0x000077d929316a70 rbx = 0x000077d8f63c3020
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - rsi = 0x000077d911b1e510 rdi = 0x000077d911b1e260
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - rbp = 0x000077d911b1e560 rsp = 0x000077d911b1e550
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - r8 = 0x0000000000000b3a r9 = 0x000077d911b22450
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - r10 = 0x000077d90aed0078 r11 = 0x0000000000000000
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - r12 = 0x000077d8f37e6400 r13 = 0x0000000000000000
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - r14 = 0x000077d8f63c3ce8 r15 = 0x000077d8f63c3ce8
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - rip = 0x000077d90aed008a
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - Found by: given as instruction pointer in context
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - 1 libxul.so!nsLayoutUtils::InflationMinFontSizeFor(nsIFrame const*) [nsLayoutUtils.cpp:33914610f60fe825ae321a774e32bd9933ff5fc6 : 8286 + 0x8]
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - rbp = 0x000077d911b1e5a0 rsp = 0x000077d911b1e570
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - rip = 0x000077d90ae59fe8
[task 2019-10-10T04:05:11.605Z] 04:05:11 INFO - Found by: previous frame's frame pointer
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - 2 libxul.so!nsLayoutUtils::FontSizeInflationFor(nsIFrame const*) [nsLayoutUtils.cpp:33914610f60fe825ae321a774e32bd9933ff5fc6 : 8318 + 0x8]
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - rbp = 0x000077d911b1e5c0 rsp = 0x000077d911b1e5b0
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - rip = 0x000077d90ae59e5e
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - Found by: previous frame's frame pointer
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - 3 libxul.so!mozilla::ReflowInput::CalcLineHeight() const [ReflowInput.cpp:33914610f60fe825ae321a774e32bd9933ff5fc6 : 2841 + 0x5]
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - rbp = 0x000077d911b1e5f0 rsp = 0x000077d911b1e5d0
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - rip = 0x000077d90ae7b4f8
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - Found by: previous frame's frame pointer
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - 4 libxul.so!mozilla::BlockReflowInput::BlockReflowInput(mozilla::ReflowInput const&, nsPresContext*, nsBlockFrame*, bool, bool, bool, int) [BlockReflowInput.cpp:33914610f60fe825ae321a774e32bd9933ff5fc6 : 152 + 0x5]
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - rbp = 0x000077d911b1e650 rsp = 0x000077d911b1e600
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - rip = 0x000077d90ae7bd07
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - Found by: previous frame's frame pointer
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - 5 libxul.so!nsBlockFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [nsBlockFrame.cpp:33914610f60fe825ae321a774e32bd9933ff5fc6 : 1237 + 0x20]
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - rbp = 0x000077d911b1ec30 rsp = 0x000077d911b1e660
[task 2019-10-10T04:05:11.606Z] 04:05:11 INFO - rip = 0x000077d90ae98947
[task 2019-10-10T04:05:11.607Z] 04:05:11 INFO - Found by: previous frame's frame pointer
[task 2019-10-10T04:05:11.607Z] 04:05:11 INFO - 6 libxul.so!nsAbsoluteContainingBlock::ReflowAbsoluteFrame(nsIFrame*, nsPresContext*, mozilla::ReflowInput const&, nsRect const&, nsAbsoluteContainingBlock::AbsPosReflowFlags, nsIFrame*, nsReflowStatus&, nsOverflowAreas*) [nsAbsoluteContainingBlock.cpp:33914610f60fe825ae321a774e32bd9933ff5fc6 : 753 + 0x21]
[task 2019-10-10T04:05:11.607Z] 04:05:11 INFO - rbp = 0x000077d911b1efb0 rsp = 0x000077d911b1ec40
[task 2019-10-10T04:05:11.607Z] 04:05:11 INFO - rip = 0x000077d90ae94581
[task 2019-10-10T04:05:11.607Z] 04:05:11 INFO - Found by: previous frame's frame pointer

Flags: needinfo?(aethanyc)
Upstream PR was closed without merging
Depends on: 1588025

Filed bug 1588025 to fix the root cause of the backout in comment 39. In the meantime, I'll disable AccessibleCaret for the font-inflation tests to work around bug 1588025, and reland my patches.

This is a try run with AccessibleCaret disabled for font-inflation tests in Part 2.

Flags: needinfo?(aethanyc)
Pushed by aethanyc@gmail.com: https://hg.mozilla.org/integration/autoland/rev/c6daecd1e4f5 Part 1 - Propagate used writing-mode from body element to its ancestors. r=jfkthame https://hg.mozilla.org/integration/autoland/rev/20bed215cb68 Part 2 - Modify the reference file for 817406-4.html, and update test expectations. r=jfkthame https://hg.mozilla.org/integration/autoland/rev/171c70db54de Part 3 - Add reftests for altering <body> dynamically. r=jfkthame https://hg.mozilla.org/integration/autoland/rev/c42855b477b1 Part 4 - Add BFC bits to a block if its used writing-mode is different from the parent's. r=jfkthame
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Upstream PR merged by moz-wptsync-bot
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox71: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Blocks: 1588986
Regressions: 992384
Blocks: 1588025
No longer depends on: 1588025
Regressions: 1593752
Regressions: 1630819
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: