Last Comment Bug 464758 - <select> with :after content doesn't open
: <select> with :after content doesn't open
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout: Misc Code (show other bugs)
: unspecified
: All All
: P2 normal with 2 votes (vote)
: mozilla15
Assigned To: Boris Zbarsky [:bz]
:
Mentors:
data:text/html,<style>select:after{co...
: 478310 640091 641941 (view as bug list)
Depends on: 763424
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-13 12:35 PST by Simon Bünzli
Modified: 2012-06-11 08:54 PDT (History)
7 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test case for div :after (1.04 KB, text/html)
2009-02-12 13:16 PST, matt
no flags Details
Don't try to check for :before/:after pseudos for frames that can't have them. (7.35 KB, patch)
2012-05-14 20:37 PDT, Boris Zbarsky [:bz]
dbaron: review+
Details | Diff | Splinter Review

Description Simon Bünzli 2008-11-13 12:35:43 PST
Testcase in the URL. Broken in at least in Firefox 3.0 and on Trunk.
Comment 1 Boris Zbarsky [:bz] 2008-11-13 19:13:07 PST
This is due to the fact that when we reresolve style we detect that there is no generated content, that the style says there should be, so we reframe the whole thing.  I was pretty sure we had a bug on this, but I can't find it.   Of course I was sure there's a bug on us reframing on the generated content thing for replaced elements, and I can't find that either....

David, seems to me it would be nice to have a way to flag frames as needing to skip this check (or alternately needing to do this check) in ReResolveStyleContext.
Comment 2 matt 2009-02-12 13:12:17 PST
This also happens if the <select> is contained in a <div> with :after.  Attaching testcase.
Comment 3 matt 2009-02-12 13:16:31 PST
Created attachment 362090 [details]
Test case for div :after
Comment 4 Boris Zbarsky [:bz] 2009-02-12 13:23:42 PST
Actually, that's subtly different from this bug as originally reported.  I'm not sure offhand why the issue comes up in that case, and you should probably file a separate bug on it.
Comment 5 matt 2009-02-12 15:39:04 PST
Ok I can do that too.  Thanks for the fast reply.  I'll try to get the bug filed tonight, pardon the misfile.
Comment 6 matt 2009-02-12 16:52:21 PST
Per your recommendation, I've created a new bug and attached the test case; its locatable at:
https://bugzilla.mozilla.org/show_bug.cgi?id=478310
Comment 7 Boris Zbarsky [:bz] 2009-02-13 09:08:29 PST
*** Bug 478310 has been marked as a duplicate of this bug. ***
Comment 8 Boris Zbarsky [:bz] 2011-03-08 22:45:51 PST
*** Bug 640091 has been marked as a duplicate of this bug. ***
Comment 9 philippe (part-time) 2011-03-15 16:26:26 PDT
*** Bug 641941 has been marked as a duplicate of this bug. ***
Comment 10 Boris Zbarsky [:bz] 2011-03-26 08:25:39 PDT
We have more frame bits now; this should be fixable.
Comment 11 Seth Borg 2012-05-01 10:12:43 PDT
When using element:after { content:"."; } or any other content: except normal, the first click on a SELECT drop down menu field sets the focus. The second click opens the dropdown menu. Tested on IE9 and Chrome 18.0.1025.168 m with no such problems.

<style>
.example:after {
	content:".";
/* below is not really necessary but height:0; makes the period not appear */
	display:block;
	clear:both;
	visibility:hidden;
	height:0;
	overflow:hidden;
}
</style>

<select name="State" class="example">
<option value="">Select</option>
<option value="AL">Alabama</option>
</select>
Comment 12 Seth Borg 2012-05-01 10:14:19 PDT
Note, this is still broken as of Firefox 12
Comment 13 Boris Zbarsky [:bz] 2012-05-14 20:37:44 PDT
Created attachment 623927 [details] [diff] [review]
Don't try to check for :before/:after pseudos for frames that can't have them.
Comment 14 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2012-05-25 17:17:26 PDT
Comment on attachment 623927 [details] [diff] [review]
Don't try to check for :before/:after pseudos for frames that can't have them.

r=dbaron (though it seems like it might be a waste of a bit)

Also, do you really want to remove the !pseudoTag check (esp. given you're marking all inlines)?
Comment 15 Boris Zbarsky [:bz] 2012-05-25 18:52:55 PDT
> Also, do you really want to remove the !pseudoTag check (esp. given you're marking all
> inlines)?

Oh, good catch.  I forgot about the inline case.  I'll reinstate the !pseudoTag check.
Comment 17 Ed Morley [:emorley] 2012-05-30 07:35:49 PDT
https://hg.mozilla.org/mozilla-central/rev/b6a280a82658

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