<select> with :after content doesn't open

RESOLVED FIXED in mozilla15

Status

()

Core
Layout: Misc Code
P2
normal
RESOLVED FIXED
9 years ago
5 years ago

People

(Reporter: Simon Bünzli, Assigned: bz)

Tracking

unspecified
mozilla15
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
Testcase in the URL. Broken in at least in Firefox 3.0 and on Trunk.
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.
Component: Layout: Form Controls → Layout: Misc Code
QA Contact: layout.form-controls → layout.misc-code

Comment 2

8 years ago
This also happens if the <select> is contained in a <div> with :after.  Attaching testcase.

Comment 3

8 years ago
Created attachment 362090 [details]
Test case for div :after
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

8 years ago
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

8 years ago
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
Duplicate of this bug: 478310
Duplicate of this bug: 640091

Updated

6 years ago
Duplicate of this bug: 641941
We have more frame bits now; this should be fixable.
Assignee: nobody → bzbarsky
Priority: -- → P2

Comment 11

5 years ago
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

5 years ago
Note, this is still broken as of Firefox 12
Created attachment 623927 [details] [diff] [review]
Don't try to check for :before/:after pseudos for frames that can't have them.
Attachment #623927 - Flags: review?(dbaron)
Whiteboard: [need review]
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)?
Attachment #623927 - Flags: review?(dbaron) → review+
> 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.
https://hg.mozilla.org/integration/mozilla-inbound/rev/b6a280a82658
Flags: in-testsuite?
Whiteboard: [need review]
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/b6a280a82658
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Depends on: 763424
You need to log in before you can comment on or make changes to this bug.