82547 - Mouse events are not going to Composer when clicking on "input" and other form elements in a page being edited.

Status: RESOLVED INVALID

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[rubydoo123]

using build from May 23:
1. open an existing file with a textarea element within Composer
2. select the content area of the textarea, the textarea frame is selected (blue 
outline)
3. if default text is within the textarea, dbl-click selects the text and the 
frame, if no default text, just the frame is selected.

problems:
1. at this point if you type, the textarea is deleted (I expected something 
similar to when I select within a table)
2. dbl-click does not render the dialog

<textarea name="textarea test" rows=6 cols=30>TEXTAREA 
element</textarea><br><br>
<textarea name="textarea test" rows=6 cols=30></textarea>

Comment 1

[Charles Manske]

Yuck! Editing a textarea in an editor is tricky! By your description, we are
mixing the textarea as an element to be inserted with the textarea as something
you can edit in! You should never be able to type "inside" the textarea, i.e.,
it should not be a "live" editor itself, only a "read-only" representation of
the HTML element. We need some way of supressing all events that think the
textarea can have its *content* edited. Double-click event is going to the
the "inside" of the textarea, thus selecting the word. That shouldn't happen,
and it is why dblclick doesn't bring up properties dialog.
Your problem 1 (delete the textarea when you type) is actually correct behavior:
you've selected the textarea as an object in the page, and typing always deletes
what's selected.
We definitely have some way to go before we can edit form elements.

Comment 2

[rubydoo123]

it would be outstanding if we could somehow make it unselectable content, but 
able to grab the frame so the user can display the properties -- would that be 
possibly?

Comment 3

[Charles Manske]

Yes, that should be possible. Adding Daniel, the god of CSS.

Comment 4

[Simon Fraser [no longer active]]

Maybe we just need some user-input and/or user-select style for textarea (using, 
of course, our moz-user-select et al.)

Comment 5

[Simon Fraser [no longer active]]

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

Comment 6

[Kathleen :Brade]

also: note that you can't bring up the context menu on Mac for any form elements.

Comment 7

[Charles Manske]

I like my Summary from bug 85239 better! It really has nothing to do with
Advanced properties dialog.

Comment 8

[Syd Logan]

spam composer change

Comment 9

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 10

[Charles Manske]

Yikes! I shouldn't have this. Events/selection group should! 

Comment 11

[Charles Manske]

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

Comment 12

[Charles Manske]

Editing a page with form elements is a mess! Caret will go into an input widget
and "get lost". Caret will disappear. This needs to be considered for 1.0.

Comment 13

[Syd Logan]

Not EDITORBASE, form editing not applicable to typical users

Comment 14

[Charles Manske]

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

Comment 15

[[e-mail]]

Attachment: Proposed patch

-moz-user-input: auto; actually works with some widgets.

Comment 16

[[e-mail]]

Attachment: Addressed glazou's comment :-)

Comment 17

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Comment on attachment 99964 [details] [diff] [review]
Addressed glazou's comment :-)

r=glazman

Comment 18

[kinmoz]

Comment on attachment 99964 [details] [diff] [review]
Addressed glazou's comment :-)

sr=[e-mail]

Comment 19

[kinmoz]

That is sr=[e-mail] as long as select/comboboxes don't show their menus
when you click on them.

Comment 20

[[e-mail]]

Attachment: Found a regression :-(

Stop <input disabled> grabbing the caret (wierd one, that).

Comment 21

[Kathleen :Brade]

Comment on attachment 110590 [details] [diff] [review]
Found a regression :-(

seek reviews from previous reviewers

Comment 22

[kinmoz]

Comment on attachment 110590 [details] [diff] [review]
Found a regression :-(

Neil, do readonly inputs grab the caret too?

Comment 23

[kinmoz]

Comment on attachment 110590 [details] [diff] [review]
Found a regression :-(

I'm fine with the "disabled" change, just check to see if "readonly" needs the
same treatment. sr=[e-mail]

Btw, the -moz-user-select and -moz-user-focus properties are already in effect
for most of the selectors (inputs) for the 2nd rule because of the first rule.
Do we just want to use the 2nd rule to override just the -moz-user-input prop?


input, button, select, textarea {
  -moz-user-select: all !important;
  -moz-user-input: auto !important;
  -moz-user-focus: none !important;
}

select, input[disabled], input[type="checkbox"], input[type="radio"],
input[type="file"] {
   -moz-user-input: none !important;


Guess it doesn't matter.

Comment 24

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Comment on attachment 110590 [details] [diff] [review]
Found a regression :-(

r=glazman

Comment 25

[Asa Dotzler [:asa]]

Comment on attachment 110590 [details] [diff] [review]
Found a regression :-(

a=asa (on behalf of drivers) for checkin to 1.3 final.

Comment 26

[[e-mail]]

Comment on attachment 110590 [details] [diff] [review]
Found a regression :-(

Obsoleting checked-in attachment but some issues still remain.

Comment 27

[saari (gone)]

What are the remaining issues here?

Comment 28

[saari (gone)]

needs qa verification and help with figuring out the remaining issues

Comment 29

[rubydoo123]

There are still a few problems. I will attach a test case after this description
of what to do.

1. save the attached test case to your system
2. open the attached test case in composer
3. set your caret to the last line of text above the textarea, either arrow over
or hit end to get to the end of that line.
4. hit the right arrow, the caret will render within the text area, enter some
additional text, make sure you hit enter (for a later test) and have 2 lines of
text. Select save.

The user would expect the text that was just entered to actually be in the
textarea. It isn't. Toggle to HTML Source and look at what the text is. Or view
the file in the browser.

Now, go back to the composer window, repeat steps #2 & #3 -- when I do this, the
caret movement will not move from left to right within the textarea, it will
arrow down. When I get to the 2nd line, if I left arrow, it will move to the end
of the first line in the textarea, however, if I hit the left arrow again, the
caret is moved to the end of the last line of text above the textarea.

Comment 30

[rubydoo123]

Attachment: test case

test case for the above steps

Comment 31

[http://tinymailto.com/oliversl]

Maybe related to bug #195361.
I post here beacuse kin sugested that the patch of this bug maybe can solve the
issue described in bug #195361.
I tested bug #195361 with Mozilla 1.3b BuildID 2003022709

Comment 32

[Kevin McCluskey (gone)]

EDITORBASE+

Comment 33

[Kai Engert (:KaiE:)]

So the reported remaining issue is with editing the initial text in a form's
textarea.

Are we supposed to allow the user to do this at all? I tried to focus the text
in the textarea using the mouse. That's not possible at all! One can select the
textarea, but not place the caret in it.

I guess that it is a bug that keyboard navigation can be used to enter the
textarea contents? Only keyboard navigation can currently be used to enter it.
But, you can not do correct keyboard movement once you inside. Home and enter
work, but you can not use left/right to navigate inside the textarea. One can
enter text at the beginning or at the end of the textarea, but not in the
middle. And worse, when I look at the HTML source, the text I'm entering does
not even get added to the textarea! Once during my tests switching between
source and normal view, I even crashed...

I suggest we disable the ability to enter the textarea using keyboard navigation.

Do you agree?
Should this be done in this bug, or in a new separate bug?

Comment 34

[Simon Fraser [no longer active]]

Form controls in composer should be treated like atomically selectable and
deletable objects due to the -moz-user-select style that is applied to them. It
should not be possible to select the contents of a textarea, though, ideally, it
should be possible to bring up a 'properties' dialog, and alter element
properties through that.

Comment 35

[Vedran Miletic]

retargeting

Comment 36

[Laurent Jouanneau]

In Gecko 1.9, controls are atomically selectable (-moz-user-select:all).

So this bug is now deprecated.