Textboxes and textareas with :before or :after styles are submitted as empty. In addition, the "Cut" operation on such a text field deletes text without copying it to the clipboard. This is a recent regression: it happens in 6/14 but does not happen in 6/7. I have my user style sheet set to generate hints for accesskeys. The following pages use accesskeys for text fields: http://www.cs.hmc.edu/~jruderma/s/ (search fields, 1-8) http://www.msn.com/ (search field, S) http://bugzilla.mozilla.org/show_bug.cgi?id=33830 (add-comment field, C)
Assignee: rods → kin
As a note, those are replaced inline elements and we should not even be applying :before/:after to them....
*** Bug 155959 has been marked as a duplicate of this bug. ***
Does this still happen with recent builds?
Jesse, mind posting a testcase for this bug?
http://compsoc.dur.ac.uk/~de/inputs.html was the test case for 155959 (still does not submit the data in 1.1beta)
OK. So the problem here is that nsGenericHTMLElement::GetFormControlFrameFor() calls GetPrimaryFrameFor() on the content node. That gives the _wrapper_ frame in this case, instead of the real form control frame. Chaos ensues. Possible fixes: 1) Stop applying :before/:after to replaced inline elements. (I like this one, myself). We would need to make <hr> not break if we did this. 2) Hack GetFormControlFrameFor() to get the right frame (either by walking the childlist of the frame it gets looking for an nsIFormControlFrame or by maintaining a mapping in the framemanager that maps wrapper frames to the "real" frames). 3) Have a GetContentFrameFor() function that's just like GetPrimaryFrameFor except in the case when the primary frame is a wrapper frame around :before/:after. Then GetFormControlFrameFor() can just call GetContentFrameFor() jkeiser seems to favor option #3 (since various things like XBL form controls, offset* on images that have :before/:after, etc. may want this functionality). David? What do you think?
OS: Windows XP → All
Hardware: PC → All
For the record, I actually favor #1 if at all possible :) #3 is the substitute if people really need :before and :after on leaf elements, but it really complicates our lives and doesn't fit the spec at all.
My real preference is: 4) Make form controls store data in the content and therefore not need access to the frames in order to submit. I was actually for (1), and I brought it up in the CSS working group, but others were against it. Failing (4), I'd actually prefer (2), since I think (4) is the long term fix and (3) is otherwise unneccesary.
(4) is implausible for several reasons. We already store most data in content, but for editor, we would take a real performance hit; that is why input type=text is the one control that does *not* store its data in content when the editor is around. A complicated copy would be required from the editor to the control on every keystroke (and not just a simple copy from textnode; it has to unflatten frames, since it is the same control as textarea). Further, form controls need to send events to frames on occasion. This means they have to be able to find the proper frame. We could find a way to get around that as well by creating listener interfaces, if need be. Given that there is a legitimate need to find the frame that relates to a piece of content, it seems best to make a legitimate function (3), instead of a hack that only works for form controls (2). It is sad that we can't do (1), but I guess them's the breaks.
*** Bug 168312 has been marked as a duplicate of this bug. ***
Is this still important? Generated content on "replaced" elements has been disabled.
This was fixed way back when anyway. *** This bug has been marked as a duplicate of 155957 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.