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 :)
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&mdtargeturl=http%3A%2F%2Fboards.excite.com%2Fboards%2Feditmessage%3Fid%3D10%3A120763%26msgIndex%3D5"> 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>
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
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?
Severity: blocker → normal
Summary: [Parity] Edit box acts as a link in Excite Message Boards → edit box (text input) inside link acts as a link when clicked
Assignee: clayton → joki
HTML Form Controls?
Assignee: joki → rods
Component: HTML Element → HTML Form Controls
QA Contact: lorca → bsharma
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
when editing the page, I cannot get focus within either the textarea or the input field. Sending to sfraser for review.
Assignee: beppe → sfraser
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
<!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>.
<FORM> isn't, but <TEXTAREA> is, yes. Dunno why the HTML WG did _that_ though.
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).
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.
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.
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
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Target Milestone: mozilla0.9.1 → Future
QA Contact Update
QA Contact: bsharma → vladimire
*** Bug 104452 has been marked as a duplicate of this bug. ***
Summary: Can't edit in textarea that is inside a link → Can't edit a form field that is inside a link
14 years ago
Depends on: 234455
This "bug" still exists.
Assignee: saari → nobody
Status: ASSIGNED → NEW
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)
Created attachment 229961 [details] [diff] [review] + missing NS_FOCUS_CONTENT
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] + 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...
You need to log in before you can comment on or make changes to this bug.