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

Assigned to



Layout: Form Controls
18 years ago
12 years ago


(Reporter: Brian 'netdragon' Bober, Assigned: smaug)




Firefox Tracking Flags

(Not tracked)



(3 attachments, 1 obsolete attachment)



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

18 years ago
I think the problem is bad HTML.  It looks like the entire form is enclosed in a
- Nov 06,2000
some text taht I typed....


<form method="Post" action="/boards/processeditmessage?msgIndex=5"><br>
<textarea defaultvalue="um..." value="um..." name="body" rows="10" cols="70"
<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>
Ever confirmed: true

Comment 2

18 years ago
Created attachment 18842 [details]
testcase of the problem in case it goes away

Comment 3

18 years ago
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. 
Assignee: asa → clayton
Component: Browser-General → HTML Element
QA Contact: doronr → lorca

Comment 4

18 years ago
Created attachment 18848 [details]
shorter testcase

Comment 5

18 years ago
Updating summary, setting severity to normal, adding testcase keyword. says it's 
legal to have a textarea or input inside a link... is that correct?
Severity: blocker → normal
Keywords: testcase
Summary: [Parity] Edit box acts as a link in Excite Message Boards → edit box (text input) inside link acts as a link when clicked
Please triage.
Assignee: clayton → joki
HTML Form Controls?
Assignee: joki → rods
Component: HTML Element → HTML Form Controls
QA Contact: lorca → bsharma

Comment 8

18 years ago
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
Assignee: rods → beppe

Comment 9

18 years ago
when editing the page, I cannot get focus within either the textarea or the 
input field. Sending to sfraser for review.
Assignee: beppe → sfraser

Comment 10

18 years ago
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.
Assignee: sfraser → akkana
Summary: edit box (text input) inside link acts as a link when clicked → Can't edit in textarea that is inside a link

Comment 11

18 years ago
<!ELEMENT A - - (%inline;)* -(A)       -- anchor -->
<!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">
As Jesse said, it looks like <FORM> is valid in <A>, the question is whether 
the event should reach the <A>.
<FORM> isn't, but <TEXTAREA> is, yes. Dunno why the HTML WG did _that_ though.

Comment 13

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

18 years ago
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.


18 years ago
Assignee: akkana → saari

Comment 15

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

17 years ago
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
Target Milestone: --- → mozilla0.9.1

Comment 17

17 years ago
Target Milestone: mozilla0.9.1 → Future

Comment 18

17 years ago
QA Contact Update
QA Contact: bsharma → vladimire

Comment 19

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


17 years ago
Summary: Can't edit in textarea that is inside a link → Can't edit a form field that is inside a link

Comment 20

14 years ago
This "bug" still exists.
Assignee: saari → nobody
QA Contact: vladimire → core.layout.form-controls
Created attachment 229953 [details] [diff] [review]
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)
Attachment #229953 - Flags: superreview?(bzbarsky)
Attachment #229953 - Flags: review?(bzbarsky)
Created attachment 229961 [details] [diff] [review]
Assignee: nobody → Olli.Pettay
Attachment #229953 - Attachment is obsolete: true
Attachment #229961 - Flags: superreview?(bzbarsky)
Attachment #229961 - Flags: review?(bzbarsky)
Attachment #229953 - Flags: superreview?(bzbarsky)
Attachment #229953 - Flags: review?(bzbarsky)
Why not just call PreventDefault on events as necessary?
(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.
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 on attachment 229961 [details] [diff] [review]

Argh, not good. Otherwise this would work ok, but XTF's handleDefault doesn't like this and XForms would be broken...
Attachment #229961 - Flags: superreview?(bzbarsky)
Attachment #229961 - Flags: review?(bzbarsky)
You need to log in before you can comment on or make changes to this bug.