Open Bug 1326551 Opened 3 years ago Updated 3 years ago
Background rendering incomplete in (display: table-row) with (direction: rtl) on resize
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20161209095719 Steps to reproduce: 0. Use Firefox on Ubunutu (latest from the Ubuntu repository, Firefox 50.1.0) - did not yet test this on other platforms 1. Create a table width DIVs, based on CSS display: table, table-row, table-cell 2. Gave one of the rows a background color 3. Set text direction: rtl (right-to-left) 4. Resized window very small (width) and then large again (depends on test case) Actual results: The background for the table row is not rendered completely (see screenshot). In a more complex layout (more rows) this also happens without resizing. The problem went worse when opening the developer console. Therefore, I assume it's a performance issue. Please see attached screenshots for example. Expected results: The background should fill the whole table row.
Coukd you just provide a testcase as html file like on jsfiddle or codepen, please.
Ah .. JSFiddle is a good idea for that. Here's the test case: https://jsfiddle.net/xgp50efy/ Please resize the output window small and then large again to see the issue. (Tested with Firefox 50.1.0 under Ubuntu 16.04)
Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a38c23ccca0a&tochange=be81b8d6fae9 It could be a regression from bug 1169440. David, what do you think?
Component: Layout: Block and Inline → Layout
Flags: needinfo?(mail) → needinfo?(dbaron)
Version: 50 Branch → 41 Branch
Seems much more likely to be a regression from bug 1174700 (also in that range).
Flags: needinfo?(dbaron) → needinfo?(jfkthame)
Narrowing regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cd741d3ae78a&tochange=ed293fc9596c
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
(In reply to David Baron :dbaron: ⌚️UTC-8 from comment #4) > Seems much more likely to be a regression from bug 1174700 (also in that > range). Yes, that'll surely be it. Interesting that the testcase only exhibits the problem when the table cells have position:relative; if I remove that, I can no longer reproduce. Another version of the issue: open the testcase (attachment 8823134 [details]), and use the Dev Tools inspector to look at the style of one of the table cells. Click the checkbox to disable the "position: relative" property on it: no visible change (as expected). Then click it again to re-enable the "position: relative" property: cell background disappears. Slightly resizing the window makes it reappear.
Hi Jonathan, we looked at this in regression triage today. Is this bad enough to get an assignee (or a backout), or leave it for a later fix?
(In reply to David Bolter [:davidb] from comment #7) > Hi Jonathan, we looked at this in regression triage today. Is this bad > enough to get an assignee (or a backout), or leave it for a later fix? It looks like this is limited to a pretty specific (and rare, I guess) combination of circumstances, and it's more of a cosmetic than a crippling failure, such that I don't think a backout is called for (and trying to back out bug 1174700 at this point would carry substantial risk of its own). I wouldn't consider it a top priority, either, though it's certainly a valid bug we should fix.
Given comment 8 I'm letting this fall off of our weekly platform triage. Would it make a good first bug?
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #10) > Given comment 8 I'm letting this fall off of our weekly platform triage. > Would it make a good first bug? Probably not; my gut feeling is that it's a layout issue that may be tricky to get right, and will depend on understanding reflow and frame coordinate management in some depth.
You need to log in before you can comment on or make changes to this bug.