text fields with :before or :after generated content submit as empty




17 years ago
15 years ago


(Reporter: jruderman, Assigned: kinmoz)


({dataloss, regression})

dataloss, regression

Firefox Tracking Flags

(Not tracked)




17 years ago
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)


17 years ago
Keywords: dataloss

Comment 1

17 years ago
Assignee: rods → kin
As a note, those are replaced inline elements and we should not even be applying
:before/:after to them....

Comment 3

17 years ago
*** Bug 155959 has been marked as a duplicate of this bug. ***

Comment 4

17 years ago
Does this still happen with recent builds?
Keywords: regression
Jesse, mind posting a testcase for this bug?

Comment 6

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

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

Comment 8

17 years ago
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. ***


16 years ago
Priority: -- → P2
Target Milestone: --- → Future

Comment 12

15 years ago
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 ***
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.