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

Status: RESOLVED DUPLICATE of bug 155957

(Core :: Layout: Form Controls, defect, P2)

Description

[Jesse Ruderman]

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)

Comment 1

[rods (gone)]

-->

Comment 2

[Boris Zbarsky [:bzbarsky]]

As a note, those are replaced inline elements and we should not even be applying
:before/:after to them....

Comment 3

[Anthony DeRobertis]

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

Comment 4

[Anthony DeRobertis]

Does this still happen with recent builds?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Jesse, mind posting a testcase for this bug?

Comment 6

[David Emmerson]

http://compsoc.dur.ac.uk/~de/inputs.html was the test case for 155959 (still
does not submit the data in 1.1beta)

Comment 7

[Boris Zbarsky [:bzbarsky]]

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?

Comment 8

[John Keiser (jkeiser)]

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.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 10

[John Keiser (jkeiser)]

(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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

*** Bug 168312 has been marked as a duplicate of this bug. ***

Comment 12

[Anne (:annevk)]

Is this still important? Generated content on "replaced" elements has been disabled.

Comment 13

[Boris Zbarsky [:bzbarsky]]

This was fixed way back when anyway.

*** This bug has been marked as a duplicate of 155957 ***