Open Bug 293771 Opened 16 years ago Updated 4 months ago
Placing form fields inside a design
Mode (midas) area behaves strangely .
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 When using the Midas engine (setting designMode on) if a form field is part of the html being edited, some odd behaviour is noted. See steps to reproduce... Reproducible: Always Steps to Reproduce: 1. Go to the URL http://www.mozilla.org/editor/midasdemo/ and type "Hello World" in the area 2. Click the View HTML Source checkbox 3. Add "<input type="text" name="foo" value="bar" />" to the area 4. Uncheck the View HTML Source checkbox 5. Click the field, it will be selected (highlighted) 6. Click anywhere else in the area (not on the field), the field will de-select but has now gained caret focus 7. Type some stuff in the field 8. Click somewhere in "Hello World" and enter some text 9. Click the View HTML Source checkbox again 10. Note that while the change to "Hello World" works correctly, the field's value is unchanged. Actual Results: First, the field erroneously (IMHO) gained focus and allowed the user to type, however when viewing the source it is apparent that the text the user enters in the field is not recorded at all. Expected Results: The user should not be able to gain a caret in the field, or if the user is able to then the changes should be properly recorded.
Further to the above, and all related I expect (hence why not filing a separate bug), the following are also problems when placing fields in a designMode iframe.. It is "tricky" to select fields sometimes, it's necessary to click "on the edge" of the field. Clicking a select does not bubble an onclick to the iframe document, same for checkboxes and radio buttons. Clicking a button does not select it, but actually clicks it. To select it you must very strangely click slightly off the side of the button by a few pixels, but not too far.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → EXPIRED
Still an issue.
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070206 Minefield/3.0a2pre It seems to be fixed. But still reproduces if you navigate using the keyboard backwards, from end to start: the selection cursor will enter the input type text. But another bug: - the selection cursor is hidden by the input type text or textarea if the selection is exactly before (see http://www.mister-pixel.com/ever/bugs/firefox/midas.293771.html) Another bug 1. paste the following HTML in "view source mode": "abcdefdd<textarea></textarea>" 2.return to design mode 3. put the cursor/click on text 4. move the selection using the RIGHT key until it enters inside the textarea 5. type inside the textarea; the value is not preserved in source code; if you press BACKSPACE the whole textarea is deleted 6. this reproduces if only the textarea is the last node in BODY or the next sibling is a node other than BR or TEXT_NODE (does not reproduce if textarea is followed by a BR or a nonWhiteSpace textnode)
Component: General → Editor
Product: Firefox → Core
QA Contact: general → editor
This is still an issue in firefox 3 [windows]. See also this report: http://dev.fckeditor.net/ticket/2294
Bug still exists in FF 3.0.3 windows. I don't have any other OS so I cannot confirm those. Enter following into http://www.mozilla.org/editor/midasdemo/ source: <form action="test"> <input name="txtFieldWorks" type="text" /> <br /> <input name="problem1" type="radio" /> Radio<br /> <input name="problem2" type="checkbox" /> Checker<br /> <select name="problem3"><option>One</option><option>Two</option></select> <br /> <textarea name="txtAreaWorks"></textarea> </form> Doubleclick checkbox, radio or select. Those don't get selected only textfield and textarea can be selected.
Another year goes by, this problem persists in 3.5.4 Ubuntu (not checked others). Matti's test in comment #7 illustrates it easily. I'll point out that this is a regression, previous to version 3, it was possible, but sometimes tricky, to select - http://trac.xinha.org/ticket/1270
How this can still be unconfirmed? Problem still exists in FF 3.5.5
This is definitely broken as of FF 3.5.7 and needs to be fixed, if possible.
Confirmed with FF3.6, if you don't intend to fix the bug, could you make the 'mousedown'/'click' event ticking so we developers could even have a chance to make it right?
Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.