Last Comment Bug 763424 - CSS ::after doesn't work for <td> (dynamically)
: CSS ::after doesn't work for <td> (dynamically)
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: 15 Branch
: x86 Linux
: -- normal (vote)
: mozilla16
Assigned To: Boris Zbarsky [:bz]
:
Mentors:
http://jsfiddle.net/z62Pr/
Depends on:
Blocks: 464758
  Show dependency treegraph
 
Reported: 2012-06-11 02:55 PDT by Dan Wolff
Modified: 2012-07-18 17:37 PDT (History)
3 users (show)
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed
+
fixed


Attachments
Test case, showing ::after dynamic change for a <span> and a <td> (556 bytes, text/plain)
2012-06-11 02:55 PDT, Dan Wolff
no flags Details
Dynamic changes to generated content don't work correctly on frames which pass a child content insertion frame to ProcessChildren (e.g. <td>). (8.48 KB, patch)
2012-06-11 10:23 PDT, Boris Zbarsky [:bz]
dbaron: review+
akeybl: approval‑mozilla‑aurora+
Details | Diff | Review

Description Dan Wolff 2012-06-11 02:55:54 PDT
Created attachment 631838 [details]
Test case, showing ::after dynamic change for a <span> and a <td>

Using Firefox 15.0a2 (2012-06-09) on Ubuntu 12.04.

If a selector containing ::after begins to match a <td>, the ::after is still not shown.

In the test case changing a class of a parent *should* cause the ::after to be shown, but it only works for the <span>, not the <td>.
Comment 1 Dan Wolff 2012-06-11 03:02:30 PDT
Comment on attachment 631838 [details]
Test case, showing ::after dynamic change for a <span> and a <td>

Use jsFiddle instead of attachment: easier to try out.
Comment 2 Boris Zbarsky [:bz] 2012-06-11 08:54:55 PDT
This is a regression from bug 464758 caused by the fact that the NS_FRAME_MAY_HAVE_GENERATED_CONTENT is on the anonymous block, not on the cell frame.

Requesting tracking for the regression.
Comment 3 Boris Zbarsky [:bz] 2012-06-11 10:23:09 PDT
Created attachment 631936 [details] [diff] [review]
Dynamic changes to generated content don't work correctly on frames which pass a child content insertion frame to ProcessChildren (e.g. <td>).

This doesn't regress bug 464758, because the combobox dropdown does not in fact allow generated content, so the insertion frame there doesn't have the bit set.
Comment 4 Boris Zbarsky [:bz] 2012-06-11 10:25:22 PDT
Dan, thanks for the bug report and the testcase!
Comment 5 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2012-06-11 10:25:42 PDT
Comment on attachment 631936 [details] [diff] [review]
Dynamic changes to generated content don't work correctly on frames which pass a child content insertion frame to ProcessChildren (e.g. <td>).

r=dbaron
Comment 7 Boris Zbarsky [:bz] 2012-06-11 15:27:05 PDT
Comment on attachment 631936 [details] [diff] [review]
Dynamic changes to generated content don't work correctly on frames which pass a child content insertion frame to ProcessChildren (e.g. <td>).

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 464758.
User impact if declined: ::before and ::after won't show up on some elements
   dynamically.
Testing completed (on m-c, etc.): Manual testing, passes automated tests in patch.
Risk to taking this patch (and alternatives if risky): Risk is low: just gets us
  closer to the behavior we used to have by allowing generated content on more
  things.  The alternative it to just back out bug 464758 (which was not an
  incredibly important bug) on aurora.
String or UUID changes made by this patch: None.
Comment 8 Graeme McCutcheon [:graememcc] 2012-06-12 03:04:47 PDT
https://hg.mozilla.org/mozilla-central/rev/f4ff27e63666
Comment 9 Alex Keybl [:akeybl] 2012-06-15 16:33:06 PDT
Comment on attachment 631936 [details] [diff] [review]
Dynamic changes to generated content don't work correctly on frames which pass a child content insertion frame to ProcessChildren (e.g. <td>).

[Triage Comment]
Since this forward fix was nominated instead of a backout, I trust it's sufficiently low risk. Additionally, we're very early in the cycle. Please land on Aurora 15.

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