293771 - Placing form fields inside a designMode (midas) area behaves strangely.

Status: UNCONFIRMED

(Core :: DOM: Editor, defect, P5)

Description

[James Sleeman]

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.

Comment 1

[James Sleeman]

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.

Comment 2

[Gervase Markham [:gerv]]

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/

Comment 3

[Gervase Markham [:gerv]]

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.

Comment 4

[James Sleeman]

Still an issue.

Comment 5

[Dan POPA]

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)

Comment 6

[Exception e]

This is still an issue in firefox 3 [windows]. See also this report: http://dev.fckeditor.net/ticket/2294

Comment 7

[Matti Järvinen]

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.

Comment 8

[James Sleeman]

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

Comment 9

[Matti Järvinen]

How this can still be unconfirmed? Problem still exists in FF 3.5.5

Comment 10

[Matthew]

This is definitely broken as of FF 3.5.7 and needs to be fixed, if possible.

Comment 11

[Garry Yao]

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?

Comment 12

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.