Closed Bug 1428670 Opened 7 years ago Closed 6 years ago

Font inflation layout regression

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Version:
56 Branch
Platform:
All
Android
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla64
Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- fixed

People

(Reporter: JanH, Assigned: JanH)

References

(Blocks 2 open bugs, Regression,
URL
)

Details

(Keywords: regression, testcase)

Attachments

(7 files)

Testcase extracted from the footnote box on the bottom
1.01 KB, text/html
Details
Screenshot_20180108-013001.png
779.98 KB, image/png
Details
bug_1428670_testcase_simplified.html
751 bytes, text/html
Details
Bug 1428670 - Part 0: Fix mixed tabs and spaces. r?dbaron
46 bytes, text/x-phabricator-request
dbaron
: review+
Details | Review
Bug 1428670 - Part 2: Correctly mark all child frames as dirty when font inflation status changes. r?dbaron
46 bytes, text/x-phabricator-request
dbaron
: review+
Details | Review
Bug 1428670 - Part 3: Store the effective container ISize within the FontInflationData. r?dbaron
46 bytes, text/x-phabricator-request
dbaron
: review+
Details | Review
Bug 1428670 - Part 1: Add reftest. r?dbaron
46 bytes, text/x-phabricator-request
dbaron
: review+
Details | Review
STR: Using Firefox for Android, enable Settings -> Accessibility -> Use system font size to enable font inflation for desktop pages and then visit http://www.hirezfox.com/km/co/co1024/d/20171227.html The layouting of the heading above the comic and of the footnote boxes at the bottom will appear broken - the font size of those elements has increased, but the line spacing of those elements hasn't. At least for me, the effect on the footnote boxes also gets worse if the page loads from the cache as opposed to the first load from the network. (And opening that tab in the dev tools Inspector via WebIDE fixes things again) The regression range I found is https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e6e712904806da25a9c8f48ea4533abe7c6ea8f4&tochange=d6bf703c5deaf1e328babd03d5e68ff2a4ffe10e, so most likely bug 1308876.
Flags: needinfo?(dbaron)
(In reply to Jan Henning [:JanH] from comment #0) > At least for me, > the effect on the footnote boxes also gets worse if the page loads from the > cache as opposed to the first load from the network. (And opening that tab > in the dev tools Inspector via WebIDE fixes things again) Presumably because if the images load somewhat slower from the network as opposed to getting them quickly from the cache, they trigger another reflow or something of the content below them?
Priority: -- → P3
(I can reproduce in Nightly on Android, FWIW.)
status-firefox60: --- → affected
status-firefox62: --- → affected
Also affects layouts like on http://www.columbia.edu/~brennan/abandoned/gct61.html, where the vertical spacing looks fine, but the text gets cut off horizontally instead.
See Also: → 1474821
See Also: 1474821 →
I've managed to get an Android build going for last year and confirmed that it really was https://hg.mozilla.org/integration/mozilla-inbound/rev/1e3130e96f03 itself that caused this. That is a build of just the preliminary patches (https://hg.mozilla.org/integration/mozilla-inbound/rev/395b6c53e42b) is still good, and likewise a build of just 1e3130e96f03 alone without all the preliminary patches is still bad. I'll try to investigate further and have simplified the test case some more - all that's needed is in fact some text inside a <body> with a fixed width.
Assignee: nobody → jh+bugzilla
Depends on: 1474771
(In reply to Jan Henning [:JanH] from bug 1474771 comment #6) > While this wasn't the actual cause of bug 1428670, I did notice during > my investigation that the font inflation code there was still relying on the > pre-bug 1308876 behaviour, were marking a parent as dirty was sufficient to > subsequently cause all children to mark themselves as dirty, too. So I was > planning to fix that particular instance as part of working on bug 1428670, > but you've saved me the trouble, thank you. Jan, I don't have an ETA for bug 1474771 (I've got a blocking issue with some a11y test, and I'm currently working on other higher-priority tasks). So if you'd like to get this bug here fixed soon-ish, I would recommend you go ahead without waiting! (Or take over bug 1474771.) Good luck ;-)
I might eventually be able to look at bug 1474771 if you didn't get around to it by that time, but conversely my priority is to fix this issue first, so for now I'll just fix the relevant bits in the font inflation code myself then.
No longer depends on: 1474771
Problem #1 I've discovered: When the font inflation data on a font inflation flow root [1] containing the relevant width used in calculating the amount of font inflation changes, we only mark that frame itself as dirty. Prior to bug 1308876, all child frames would have subsequently marked themselves as dirty, too. Now however, it's the parents responsibility to do so and the font inflation code at [2] needs to be updated accordingly. However in this case, this isn't what is actually going wrong here [3]. The first thing to note is that as of bug 707855, in addition to the pref values and the width of the relevant container, the viewport width also influences the amount of font inflation directly through [4]. With my test case, it turns out that resulting visible area is smaller than the container's size and therefore the actually relevant factor for determining the exact amount of font inflation. The second thing is that the MobileViewportManager, who is responsible for managing viewport info, only sets the initial viewport after the first paint or the "load" event, whichever happens sooner [5]. What this means though is that we've already started reflowing the page before having proper viewport data. After the initial viewport has already been set, we reflow again. Because changing the viewport also changes the visible area, in this case this also the changes the amount of font inflation we calculate as per [4] during this reflow pass. Now if the page doesn't use absolute widths, then the viewport change will presumably have marked everything as dirty [6] and the reflow will proceed correctly. If on the other hand there are page elements with a width that doesn't depend on the viewport change, I'm guessing that those elements stay clean and post-bug 1308876, clean children of dirty parents are no longer reflowed again. So we then render the increased font size within a layout assuming the original, smaller font size from the first reflow pass and the text is cutoff when it exceeds its frame boundaries. [1] Some background reading at https://web.archive.org/web/20140730170810/http://www.jwir3.com/blog/2012/07/30/font-inflation-fennec-and-you/ (with footnotes intact) or http://www.jwir3.com/font-inflation-fennec-and-you/ (with bigger images) [2] https://dxr.mozilla.org/mozilla-central/rev/c2e3be6a1dd352b969a45f0b85e87674e24ad284/layout/generic/ReflowInput.cpp#631-640 [3] For following along on Desktop, enable "dom.meta-viewport.enabled" and set font.size.inflation.emPerLine to 15, then launch the layout debugger for easier testing with the above simplified test case. [4] https://dxr.mozilla.org/mozilla-central/rev/c2e3be6a1dd352b969a45f0b85e87674e24ad284/layout/base/nsLayoutUtils.cpp#8294-8298 [5] https://dxr.mozilla.org/mozilla-central/rev/c2e3be6a1dd352b969a45f0b85e87674e24ad284/layout/base/MobileViewportManager.cpp#143,156 [6] Presumably through https://dxr.mozilla.org/mozilla-central/rev/c2e3be6a1dd352b969a45f0b85e87674e24ad284/layout/base/nsPresContext.h#474
I've got a working patch. Now I just need to turn the test case into a reftest and also hope I didn't break any existing tests along the way.
Blocks: 1380830
Is re-enabling the test from bug 1380830 sufficient?
It would be better than nothing, but it's not ideal given the fact that it only fails intermittently and also doesn't seem to fail when testing on Android itself. And after all, when it broke we originally didn't manage to find out the true cause of those intermittent failures and just ended up disabling the test instead. However I've managed to create an additional test that more closes replicates the failure conditions I've encountered and it seems to be working locally. I'm in the process of testing it on Try right now...
Bug 1308876 means that children of dirty parent frames no longer mark themselves as dirty during reflow. Instead, a dirty parent frame marks all of its children as dirty at *the start* of reflow. This means that if some code wants to mark a whole subtree as dirty *during* re- flow, it's no longer sufficient to just mark the start of the tree as dirty and then rely on all further children marking themselves as dirty, too, when reflow reaches them. The font inflation code is one such case. When the font inflation data on a font inflation flow root has become dirty, all of its children need to be marked as dirty. To that end, we pinch the proposed new MarkSubtreeDirty() function from bug 1474771 and start using it here to fix that particular case.
The magnitude of font size inflation depends on three factors: - The state of the corresponding preferences. - The calculated NCAISize of the respective font inflation flow root. - The current viewport dimensions. The first factor can currently only change when the page is being reloaded (bug 766599) and is therefore irrelevant here. A change in the second factor correctly marks all affected frames as dirty when the fix in Part 1 is taken into account. The last factor however is, as far as font inflation is concerned, only taken into account on the spot using the live value, when the required minimum font size is calculated. While a change in viewport dimensions will often mark frames as dirty, it won't do so e.g. for fixed width frames unaffected by that change. As of bug 1308876, having a dirty parent somewhere up in the frame tree is no longer sufficient to cause all of its children to reflow again, so we can now end up with the situation where a viewport change changes the font size computed by font inflation for a frame, but doesn't mark it as dirty, leading to the situation where the font size of a text doesn't match the size of its frame. This problem is commonly hit because the MobileViewportManager will only update our viewport dimensions after the first paint or the "load" event, so we will do a first reflow using the dimensions of the current window size and then a second reflow using the real viewport as decided upon by the MobileViewportManager. This will commonly be encountered on a phone, because in portrait mode this results in an intial viewport based on the screen size in the order of typically somewhere around 300 - 500 px, while our standard viewport for non-mobile- friendly pages is in fact 980 px. By moving the calculation of the effective container ISize into the calculation of the FontInflationData, we can ensure that whenever the effective ISize changes, all affected frames will be marked as dirty and correctly reflowed afterwards, regardless of whether the change was caused by a change in the NCAISize itself or the viewport dimensions. While likely only a small benefit, it also avoids having to repeatedly re- calculate the minimum of viewport dimensions and NCAISize.
I didn't manage to force the visible area to be larger than the initial window size of 800px using meta viewport tags, so I'm adjusting browser.viewport. desktopWidth for this test instead.
Comment on attachment 9008167 [details] Bug 1428670 - Part 0: Fix mixed tabs and spaces. r?dbaron David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 has approved the revision.
Attachment #9008167 - Flags: review+
Comment on attachment 9008171 [details] Bug 1428670 - Part 1: Add reftest. r?dbaron David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 has approved the revision.
Attachment #9008171 - Flags: review+
Attachment #9008171 - Attachment description: Bug 1428670 - Part 3: Add reftest. r?dbaron → Bug 1428670 - Part 1: Add reftest. r?dbaron
Attachment #9008168 - Attachment description: Bug 1428670 - Part 1: Correctly mark all child frames as dirty when font inflation status changes. r?dbaron → Bug 1428670 - Part 2: Correctly mark all child frames as dirty when font inflation status changes. r?dbaron
Attachment #9008170 - Attachment description: Bug 1428670 - Part 2: Store the effective container ISize within the FontInflationData. r?dbaron → Bug 1428670 - Part 3: Store the effective container ISize within the FontInflationData. r?dbaron
Comment on attachment 9008168 [details] Bug 1428670 - Part 2: Correctly mark all child frames as dirty when font inflation status changes. r?dbaron David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 has approved the revision.
Attachment #9008168 - Flags: review+
Blocks: 1493266
Comment on attachment 9008170 [details] Bug 1428670 - Part 3: Store the effective container ISize within the FontInflationData. r?dbaron David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 has approved the revision.
Attachment #9008170 - Flags: review+
Pushed by mozilla@buttercookie.de: https://hg.mozilla.org/integration/autoland/rev/6ecb75be4a61 Part 0: Fix mixed tabs and spaces. r=dbaron https://hg.mozilla.org/integration/autoland/rev/34736c8507e6 Part 1: Add reftest. r=dbaron https://hg.mozilla.org/integration/autoland/rev/faec1cb8ab5d Part 2: Correctly mark all child frames as dirty when font inflation status changes. r=dbaron https://hg.mozilla.org/integration/autoland/rev/1bf6b5fac1f9 Part 3: Store the effective container ISize within the FontInflationData. r=dbaron
Backed out 5 changesets (Bug 1428670, Bug 1380830) for perma failing tests/layout/generic/crashtests/742602.html Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=f38ac02fefacf6c79e945a25db824b40267a2542 Backout link: https://hg.mozilla.org/integration/autoland/rev/5688a792346d144f2f7a2ac511d8f0d84dc217c6 Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=202405719&repo=autoland&lineNumber=2357 [task 2018-09-29T19:59:56.662Z] 19:59:56 INFO - REFTEST TEST-START | http://10.0.2.2:8854/tests/layout/generic/crashtests/742602.html [task 2018-09-29T19:59:56.662Z] 19:59:56 INFO - REFTEST INFO | RESTORE PREFERENCE pref(font.size.inflation.emPerLine,0) [task 2018-09-29T19:59:56.663Z] 19:59:56 INFO - REFTEST INFO | SET PREFERENCE pref(font.size.inflation.emPerLine,15) [task 2018-09-29T19:59:56.663Z] 19:59:56 INFO - REFTEST TEST-LOAD | http://10.0.2.2:8854/tests/layout/generic/crashtests/742602.html | 244 / 361 (67%) [task 2018-09-29T20:00:17.995Z] 20:00:17 INFO - wait for org.mozilla.fennec_aurora complete; top activity=com.android.launcher [task 2018-09-29T20:00:18.199Z] 20:00:18 INFO - INFO | automation.py | Application ran for: 0:19:32.309316 [task 2018-09-29T20:00:18.200Z] 20:00:18 INFO - INFO | zombiecheck | Reading PID log: /tmp/tmp3UxSgSpidlog [task 2018-09-29T20:00:18.716Z] 20:00:18 INFO - /data/tombstones does not exist; tombstone check skipped [task 2018-09-29T20:00:19.535Z] 20:00:19 INFO - REFTEST INFO | Copy/paste: /usr/local/bin/linux64-minidump_stackwalk /tmp/tmpOq7yGT/5d9b16f8-58f7-0724-3bf8-323d1ad6aa4b.dmp /builds/worker/workspace/build/symbols [task 2018-09-29T20:00:29.716Z] 20:00:29 INFO - REFTEST INFO | Saved minidump as /builds/worker/workspace/build/blobber_upload_dir/5d9b16f8-58f7-0724-3bf8-323d1ad6aa4b.dmp [task 2018-09-29T20:00:29.716Z] 20:00:29 INFO - REFTEST INFO | Saved app info as /builds/worker/workspace/build/blobber_upload_dir/5d9b16f8-58f7-0724-3bf8-323d1ad6aa4b.extra [task 2018-09-29T20:00:29.720Z] 20:00:29 INFO - REFTEST PROCESS-CRASH | http://10.0.2.2:8854/tests/layout/generic/crashtests/742602.html | application crashed [@ nsFontInflationData::FindFontInflationDataFor(nsIFrame const*)] [task 2018-09-29T20:00:29.720Z] 20:00:29 INFO - Crash dump filename: /tmp/tmpOq7yGT/5d9b16f8-58f7-0724-3bf8-323d1ad6aa4b.dmp [task 2018-09-29T20:00:29.721Z] 20:00:29 INFO - Operating system: Android [task 2018-09-29T20:00:29.721Z] 20:00:29 INFO - 0.0.0 Linux 2.6.29-gea477bb #1 Wed Sep 26 11:04:45 PDT 2012 armv7l [task 2018-09-29T20:00:29.721Z] 20:00:29 INFO - CPU: arm [task 2018-09-29T20:00:29.722Z] 20:00:29 INFO - ARMv7 ARM Cortex-A8 features: swp,half,thumb,fastmult,vfpv2,edsp,neon,vfpv3 [task 2018-09-29T20:00:29.722Z] 20:00:29 INFO - 1 CPU [task 2018-09-29T20:00:29.722Z] 20:00:29 INFO - GPU: UNKNOWN [task 2018-09-29T20:00:29.722Z] 20:00:29 INFO - Crash reason: SIGSEGV [task 2018-09-29T20:00:29.723Z] 20:00:29 INFO - Crash address: 0x0 [task 2018-09-29T20:00:29.723Z] 20:00:29 INFO - Process uptime: not available [task 2018-09-29T20:00:29.723Z] 20:00:29 INFO - Thread 12 (crashed) [task 2018-09-29T20:00:29.724Z] 20:00:29 INFO - 0 libxul.so!nsFontInflationData::FindFontInflationDataFor(nsIFrame const*) [nsFontInflationData.cpp:f38ac02fefacf6c79e945a25db824b40267a2542 : 30 + 0x2] [task 2018-09-29T20:00:29.724Z] 20:00:29 INFO - r0 = 0x00000000 r1 = 0x9090c155 r2 = 0x60ad6a19 r3 = 0x0000001f [task 2018-09-29T20:00:29.724Z] 20:00:29 INFO - r4 = 0x0000001f r5 = 0x6d9eb8b0 r6 = 0x6d9eb0e0 r7 = 0x52af9fd8 [task 2018-09-29T20:00:29.724Z] 20:00:29 INFO - r8 = 0x00000012 r9 = 0x52afa468 r10 = 0x53df48a4 r12 = 0x00000003 [task 2018-09-29T20:00:29.725Z] 20:00:29 INFO - fp = 0x00000000 sp = 0x52af9fd0 lr = 0x5e7eb42d pc = 0x5e812d72 [task 2018-09-29T20:00:29.725Z] 20:00:29 INFO - Found by: given as instruction pointer in context [task 2018-09-29T20:00:29.725Z] 20:00:29 INFO - 1 libxul.so!nsLayoutUtils::InflationMinFontSizeFor(nsIFrame const*) [nsLayoutUtils.cpp:f38ac02fefacf6c79e945a25db824b40267a2542 : 8440 + 0x5] [task 2018-09-29T20:00:29.726Z] 20:00:29 INFO - r4 = 0x00000000 r5 = 0x6d9eb8b0 r6 = 0x6d9eb0e0 r7 = 0x52afa008 [task 2018-09-29T20:00:29.726Z] 20:00:29 INFO - r8 = 0x00000012 r9 = 0x52afa468 r10 = 0x53df48a4 fp = 0x00000000 [task 2018-09-29T20:00:29.726Z] 20:00:29 INFO - sp = 0x52af9fe0 lr = 0x5e7ad8f5 pc = 0x5e7ad8f5 [task 2018-09-29T20:00:29.727Z] 20:00:29 INFO - Found by: call frame info [task 2018-09-29T20:00:29.727Z] 20:00:29 INFO - 2 libxul.so!nsLayoutUtils::FontSizeInflationFor(nsIFrame const*) [nsLayoutUtils.cpp:f38ac02fefacf6c79e945a25db824b40267a2542 : 8475 + 0x5] [task 2018-09-29T20:00:29.727Z] 20:00:29 INFO - r4 = 0x6d9eb8b0 r5 = 0x6d9eb8b0 r6 = 0x0000bb80 r7 = 0x52afa020 [task 2018-09-29T20:00:29.727Z] 20:00:29 INFO - r8 = 0x00000012 r9 = 0x52afa468 r10 = 0x53df48a4 fp = 0x00000000 [task 2018-09-29T20:00:29.728Z] 20:00:29 INFO - sp = 0x52afa010 lr = 0x5e7ad82b pc = 0x5e7ad82b [task 2018-09-29T20:00:29.728Z] 20:00:29 INFO - Found by: call frame info [task 2018-09-29T20:00:29.729Z] 20:00:29 INFO - 3 libxul.so!mozilla::SizeComputationInput::ComputeMargin(mozilla::WritingMode, int) [ReflowInput.cpp:f38ac02fefacf6c79e945a25db824b40267a2542 : 131 + 0x5] [task 2018-09-29T20:00:29.729Z] 20:00:29 INFO - r2 = 0x00000014 r3 = 0x612c6328 r4 = 0x52afa468 r5 = 0x6d9eb8b0 [task 2018-09-29T20:00:29.729Z] 20:00:29 INFO - r6 = 0x0000bb80 r7 = 0x52afa078 r8 = 0x00000012 r9 = 0x52afa468 [task 2018-09-29T20:00:29.729Z] 20:00:29 INFO - r10 = 0x53df48a4 fp = 0x00000000 sp = 0x52afa028 lr = 0x5e7e674d [task 2018-09-29T20:00:29.730Z] 20:00:29 INFO - pc = 0x5e7e674d [task 2018-09-29T20:00:29.730Z] 20:00:29 INFO - Found by: call frame info [task 2018-09-29T20:00:29.730Z] 20:00:29 INFO - 4 libxul.so!mozilla::SizeComputationInput::InitOffsets(mozilla::WritingMode, int, mozilla::LayoutFrameType, mozilla::SizeComputationInput::ReflowInputFlags, nsMargin const*, nsMargin const*, nsStyleDisplay const*) [ReflowInput.cpp:f38ac02fefacf6c79e945a25db824b40267a2542 : 2572 + 0x9] [task 2018-09-29T20:00:29.731Z] 20:00:29 INFO - r4 = 0x52afa468 r5 = 0x0000bb80 r6 = 0x00000000 r7 = 0x52afa108 [task 2018-09-29T20:00:29.731Z] 20:00:29 INFO - r8 = 0x00000012 r9 = 0x52afa468 r10 = 0x53de9800 fp = 0x00000000 [task 2018-09-29T20:00:29.731Z] 20:00:29 INFO - sp = 0x52afa080 lr = 0x5e7e2777 pc = 0x5e7e2777 [task 2018-09-29T20:00:29.731Z] 20:00:29 INFO - Found by: call frame info [task 2018-09-29T20:00:29.732Z] 20:00:29 INFO - 5 libxul.so!mozilla::ReflowInput::InitConstraints(nsPresContext*, mozilla::LogicalSize const&, nsMargin const*, nsMargin const*, mozilla::LayoutFrameType) [ReflowInput.cpp:f38ac02fefacf6c79e945a25db824b40267a2542 : 2280 + 0x1f] [task 2018-09-29T20:00:29.732Z] 20:00:29 INFO - r4 = 0x52afa238 r5 = 0x52afa520 r6 = 0x00000000 r7 = 0x52afa220 [task 2018-09-29T20:00:29.732Z] 20:00:29 INFO - r8 = 0x00000001 r9 = 0x52afa468 r10 = 0x00000000 fp = 0x00000000 [task 2018-09-29T20:00:29.732Z] 20:00:29 INFO - sp = 0x52afa110 lr = 0x5e7e385f pc = 0x5e7e385f [task 2018-09-29T20:00:29.733Z] 20:00:29 INFO - Found by: call frame info
Flags: needinfo?(jh+bugzilla)
Seems like the assumption about writing directions doesn't hold in all cases after all. I'll look into what happens, but since it's not strictly required after all, I might just drop part 3 for now then and leave that for bug 1493266.
Flags: needinfo?(jh+bugzilla)
Could you make it an NS_ASSERTION rather than a MOZ_ASSERT and annotate the tests that hit it?
Would be a possibility, too.
So in this particular case it was the scrollbars that caused this, and the only reason we're even calculating the amount of font inflation for them is because in FontSizeInflationListMarginAdjustment, the margin calculation always calculates the amount of FontSizeInflation even when we're not actually dealing with a block frame with a bullet list [1], which is the only case in which the magnitude of font inflation really matters (I filed bug 1495323 for that). But even if we were to dismiss the scrollbars as a special case that can be sort of fixed through bug 1495323, it turns out that just taking a simple HTML document and sticking some text inside a <div> with "direction: rtl" is enough to trigger the assertion, so something about my reasoning from https://phabricator.services.mozilla.com/D5578#inline-25245 must be faulty. So I will indeed go the NS_ASSERTION route for now. [1] https://dxr.mozilla.org/mozilla-central/rev/3632445ae3db388e7b214b83acec5a042391a7bb/layout/generic/ReflowInput.cpp#131
Actually I've just noticed that the failing assertion was too strict - I'm only caring about the vertical or horizontal part of the writing direction, but the assertion in nsFontInflationData::FindFontInflationDataFor was checking for complete equality. With that bit fixed, things actually look fine locally, though I'm going to verify it on Try as well.
With the fixed assertion things look fine now I think (https://treeherder.mozilla.org/#/jobs?repo=try&revision=2dc1d5918843d66dead41f6d9dd04a0f05eb9b02), although just to be safe I've landed bug 1495323 first.
Depends on: 1495323
Pushed by mozilla@buttercookie.de: https://hg.mozilla.org/integration/autoland/rev/e2eb3d8b408f Part 0: Fix mixed tabs and spaces. r=dbaron https://hg.mozilla.org/integration/autoland/rev/205758034a6c Part 1: Add reftest. r=dbaron https://hg.mozilla.org/integration/autoland/rev/87971e291470 Part 2: Correctly mark all child frames as dirty when font inflation status changes. r=dbaron https://hg.mozilla.org/integration/autoland/rev/57e3c8d09ace Part 3: Store the effective container ISize within the FontInflationData. r=dbaron
Blocks: 1495772
Thanks for figuring all these pieces out and getting this fixed.
I'm going to assume that we want this fix to the ride the trains. Feel free to nominate the patches for Beta uplift if you feel strongly otherwise, however.
status-firefox62: fix-optional → wontfix
status-firefox63: fix-optional → wontfix
status-firefox-esr60: --- → wontfix
Flags: in-testsuite+
No longer blocks: 1308876
Regressed by: 1308876
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: