59292 - Can't edit a form field that is inside a link

Status: RESOLVED INVALID

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

Description

[Brian 'netdragon' Bober]

This bug causes a text edit box on a form to link to a page in excite. (It is 
weird too). Please do this soon or the Excite page may change.

I have build 2000101014 and 2000092908. Same thing happened in both

Click on "People and chat". 
Click on "Message boards".
Click on any of the choices for what to discuss (choose one with few messages).
Click "Add A Message"
Make an account or log in if necessary.
Try again if it didn't work.
Type "test message" and submit
Choose "Edit message"
Edit it - change it to "test: this is just a test" or something. 

Trying to place the cursor in the box to edit the message should have made the 
edit box act as a link. You should have gotten a hand when clicking on the edit 
text box.

Try the same in IE or Netscape.

Please comment on the quality of this bug submission - your opinion is greatly 
appreciated :)

Comment 1

[Asa Dotzler [:asa]]

I think the problem is bad HTML.  It looks like the entire form is enclosed in a
link
<a
href="http://www.excite.com/relocate/co=boards_membdirpv;http://members.excite.com/directory/mozillatest1?mdminlinks=1&amp;mdtargeturl=http%3A%2F%2Fboards.excite.com%2Fboards%2Feditmessage%3Fid%3D10%3A120763%26msgIndex%3D5">&nbsp;6:50pm
- Nov 06,2000
<br>
some text taht I typed....

<hr>

<form method="Post" action="/boards/processeditmessage?msgIndex=5"><br>
<textarea defaultvalue="um..." value="um..." name="body" rows="10" cols="70"
wrap="physical"></textarea>
<p> <input name="realname" type="hidden" value="mozillatest1"> <input
name="subject" type="hidden" value=" um......">
<input name="key" type="hidden" value="10:120763"> <input name="parent"
type="hidden" value="10:114079">
<input name="gparent" type="hidden" value="10:3149"> </p>
<p><input type="submit" value=" Send It! "> </p>
</form>
</a>

Comment 2

[Asa Dotzler [:asa]]

Attachment: testcase of the problem in case it goes away

Comment 3

[Asa Dotzler [:asa]]

Over to HTML element.  Confirmed with 110604 mozilla trunk build on NT4.  Looks
like bad HTML but we don't behave so poorly in 4.x

Brian Bober, this bug report is much better than some of the others.  Thanks for
taking the time to submit meaningful reports. 

Comment 4

[Jesse Ruderman]

Attachment: shorter testcase

Comment 5

[Jesse Ruderman]

Updating summary, setting severity to normal, adding testcase keyword.

http://www.utoronto.ca/webdocs/HTMLdocs/HTML_Spec/HTML3.2/a.html says it's 
legal to have a textarea or input inside a link... is that correct?

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Please triage.

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

HTML Form Controls?

Comment 8

[rods (gone)]

This is either a core layout bug (anchor element) or an editor issue. My guess 
is that the editor is letting the click bubble out - reassigning

Comment 9

[rubydoo123]

when editing the page, I cannot get focus within either the textarea or the 
input field. Sending to sfraser for review.

Comment 10

[Simon Fraser [no longer active]]

This bug has nothing to do with Composer's Edit page. It deals with a TextArea 
that is inside a link tag. So it's not my problem.

I checked that the editor does get the mouse click, and is letting it bubble. 
Whether it should or not I have no idea. Giving to editor event people.

Comment 11

[Brian 'netdragon' Bober]

<!ELEMENT A - - (%inline;)* -(A)       -- anchor -->
<!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">
<!ENTITY % formctrl "INPUT | SELECT | TEXTAREA | LABEL | BUTTON">
As Jesse said, it looks like <FORM> is valid in <A>, the question is whether 
the event should reach the <A>.

Comment 12

[Hixie (not reading bugmail)]

<FORM> isn't, but <TEXTAREA> is, yes. Dunno why the HTML WG did _that_ though.

Comment 13

[saari (gone)]

Wow, that is weird. I have no clue what the "right" behavior is in this case. I
guess it comes down to what the precedent is for inner vs. outer objects getting
control first. And that is different between 4.x and IE (top down vs. inside out
event flow). 

Comment 14

[Brian 'netdragon' Bober]

IMHO the correct action is to let the form take control because noone in their 
right mind would click a form to access a link.

Comment 15

[Akkana Peck]

Can one of the dom or event gurus (joki, saari, jst, vidur) please comment on
what we should be doing?  Don't we need to bubble mouse events (particularly if
we didn't process it) so that focus and context menus and such can do their thing?

Pass it back to me if the official word is that the editor should be calling
PreventBubble/PreventDefault on all mouse events, but I suspect that isn't right
since it isn't actually the editor that's handling the event, setting focus and
selection on left-mouse clicks.

Comment 16

[saari (gone)]

Talked to joki, and there are two options. 
1) set up anchors to not fire if our special private event has been handled 
flag is set and then have editor set that flag, or
2) fix things the way we probably need to have them fixed by doing another 
event dispatch pass. First one for the content, and then another full 
dispatch for the browser. Needless to say, that is a big job.

62152 is the same core problem

Comment 17

[Peter Trudelle]

->future

Comment 18

[Vladimir Ermakov]

QA Contact Update

Comment 19

[Jesse Ruderman]

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

Comment 20

[Brian 'netdragon' Bober]

This "bug" still exists.

Comment 21

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible patch

This is imo not very important bug, but if we want to fix it, this is one quite 
simple possibility. I guess eNO_POST_HANDLING might be useful also elsewhere.
(Note, it does not mean the same as nsEventStatus_eConsumeNoDefault - at least not now)

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

Attachment: + missing NS_FOCUS_CONTENT

Comment 23

[Boris Zbarsky [:bzbarsky]]

Why not just call PreventDefault on events as necessary?

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #23)
> Why not just call PreventDefault on events as necessary?
> 

I tried that, but ESM checks whether status is nsEventStatus_eConsumeNoDefault at least after mouse down is dispatched and doesn't change the focus.

Comment 25

[Boris Zbarsky [:bzbarsky]]

My problem is that I don't really have a good feel for what this change does, I guess.  What's the change in behavior that this introduces?  Why only for certain events?

Comment 26

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 229961 [details] [diff] [review]
+ missing NS_FOCUS_CONTENT

Argh, not good. Otherwise this would work ok, but XTF's handleDefault doesn't like this and XForms would be broken...

Comment 27

[Olli Pettay [:smaug][[e-mail]]]

Other browsers seem to have similar behavior these days.