<body> with writing-mode: vertical-rl doesn't align children to the right
Categories
(Core :: Layout: Block and Inline, defect)
Tracking
()
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)
1.74 KB,
text/html
|
Details | |
37.68 KB,
text/html
|
Details | |
1.64 KB,
patch
|
smontagu
:
review-
|
Details | Diff | Splinter Review |
4.88 KB,
patch
|
jfkthame
:
review+
|
Details | Diff | Splinter Review |
1.94 KB,
patch
|
Details | Diff | Splinter Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
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.
Comment 1•10 years ago
|
||
(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.
Reporter | ||
Comment 2•10 years ago
|
||
I filed bug 1102177 for the <hr> issue
Comment 3•10 years ago
|
||
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.
Comment 4•10 years ago
|
||
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)?
Comment 6•10 years ago
|
||
(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.
Reporter | ||
Comment 7•10 years ago
|
||
(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.
Comment 8•9 years ago
|
||
(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
Comment 9•9 years ago
|
||
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...
Comment 11•9 years ago
|
||
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
Comment 12•9 years ago
|
||
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.
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).
Comment 14•9 years ago
|
||
Comment 15•9 years ago
|
||
Same test but this time with root element having 'writing-mode: vertical-rl': http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/wm-block-flow-direction-002-root.xht Reference file: http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/wm-block-flow-direction-002-ref.xht
Comment 16•9 years ago
|
||
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.
Updated•9 years ago
|
Updated•9 years ago
|
Comment 17•9 years ago
|
||
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
Reporter | ||
Comment 18•9 years ago
|
||
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)
Reporter | ||
Comment 19•9 years ago
|
||
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.
Updated•9 years ago
|
Comment 20•9 years ago
|
||
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.
Reporter | ||
Comment 21•9 years ago
|
||
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
Comment 23•9 years ago
|
||
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.
Comment 24•9 years ago
|
||
(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.
Comment 25•8 years ago
|
||
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.
Comment 28•5 years ago
|
||
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.
Comment 29•5 years ago
•
|
||
The WG just resolved on this: https://github.com/mozilla/wg-decisions/issues/55
Assignee | ||
Comment 31•5 years ago
|
||
Assignee | ||
Comment 32•5 years ago
|
||
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
Assignee | ||
Comment 33•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 34•5 years ago
|
||
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
Updated•5 years ago
|
Assignee | ||
Comment 35•5 years ago
|
||
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.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 36•5 years ago
|
||
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
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Comment 39•5 years ago
|
||
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
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
Upstream PR was closed without merging
Assignee | ||
Comment 41•5 years ago
|
||
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.
Comment 42•5 years ago
|
||
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.
Comment 44•5 years ago
|
||
bugherder |
Upstream PR merged by moz-wptsync-bot
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Description
•