12560 - INPUT TYPE values (& OPTION items in SELECT) are selectable

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[Eli Goldberg]

* TITLE/SUMMARY
INPUT TYPE values (and OPTION items from a SELECT) are selectable

* STEPS TO REPRODUCE
0) Launch Apprunner
1) View http://slip/projects/marvin/copy-paste/copy-bad-stuff/copy-bad-stuff.html
(attached as test case)
2) Type something into the Input Fields text fields
3) Select a few items in the Option list.
4) Select and copy the entire page content
5) View the Clipboard

* RESULT
 - What happened

After step #2, note that the actual "Submit" and "Reset" button text labels are
selected.

After step #3, note that the content of the highlighted OPTION items was copied
to the Clipboard, but the content of the Input fields were not copied.

 - What was expected

Assuming from conversation with Akkana that none of the above items should be
selected or copied to the Clipboard as text; this is the behavior of IE 4.5 on
Mac, at least.

However, no specification exists to delineate the expected behavior.

* REGRESSION

 - Occurs On
        Mac OS Apprunner (1999082412 optimized build)
        Win32 Apprunner (1999082412 optimized build [NT 4, Service Pack 3])

 - Doesn't Occur On
        Internet Explorer 4.5 (Mac OS)
        Linux Apprunner (1999082412 optimized build --- button text not
highlighted; copy doesn't work at all on this page.)

* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).

Comment 1

[Eli Goldberg]

I'm not sure if this is entirely a Mike Judge issue (or, really a single bug), so
Akkana & Rod CC'd should they wish to add their $.02.

Comment 2

[Eli Goldberg]

Attachment: Test case from bug report.

Comment 3

[Eli Goldberg]

Also, the actively selected item from a pop-up menu is also displayed as selected
content. (checked Mac OS only)

Comment 4

[Eli Goldberg]

BTW, Akkana or Rod, could you please let me know if you'd like me to split out
the "copying OPTION item or a pop-up menu item to clipboard results in the
currently selected menu option's text also being copied" issue into a separate
issue, too?

(or just keep it grouped in this bug, which of course, doesn't make much sense to
me, now that I've entered it ;)

Comment 5

[Akkana Peck]

Copy just follows the selection, so it probably isn't a separate issue ...  if
the items aren't selectable then copy won't put them on the clipboard.

Comment 6

[mjudge]

hahaha this is great what a cool bug. whomever is in charge of listboxes is
trapping mouse clicks but they are passing them on. this is the problem. I am
assignin this to rod because someone whispered that he does the list
boxes/comboboxes.  davidhyatt solves this problem in the tree view maybe you
could talk to him. wait i will assign it to owner of component...

Comment 7

[Peter Trudelle]

this is an html forms control, not an xptoolkit widget. reassigning to kmcclusk

Comment 8

[Eli Goldberg]

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

Comment 9

[rods (gone)]

changed to M14

Comment 10

[rods (gone)]

The visual display is now correct, it is a question of what "content" should be 
a copy. Currently, the options of the select are being copied into the buffer, 
this may or may not be desireable. What are the requirements? Anyway it isn't a 
select bug. If somebody decides that the content of the form controls should 
NOT be included in the paste contents then that is a copy/paste mechanism bug, 
not a select bug. So a new bug should be files against the copy/paste mechanism.

So, because the visual display is not correct, I am marking this as fixed.

Comment 11

[Eli Goldberg]

Re-opening and re-assigning to Akkana, who can probably with the "After step 
#3..." section. This still occurs on 2000012108 build (Mac OS checked, will check 
Win32/Linux.)

(I'm not going to divert 15 minutes of testing time to write up a separate bug 
report when this one already explains the issue quite clearly.)

Comment 12

[Eli Goldberg]

Reassigning to Akkana, who probably either gets this bug, or knows who should.

Comment 13

[Akkana Peck]

I didn't understand this bug before, but after talking with Eli and Joe, I think
I understand what's missing at this point: that on plaintext copies, we should
not copy the contents of the select element.  I can do that part in the output
system, and am accepting the bug on that basis.  If there are other things that
also need to be done, someone please clarify so I don't miss it.

Comment 14

[Akkana Peck]

Checked in a fix.  Now we won't output any of the children of SELECT tags in
plaintext output.

I thought it might be useful if it figured out which tag was selected, and sent
that to the output, but that wasn't what people were asking for and it was
harder, so I didn't do it this time around.  If anyone wants that, file a new
bug (don't use this one, it covers too many issues already) on me.  If no one
does, I'll assume nobody want that feature.

Comment 15

[Eli Goldberg]

Looks fixed using 2000021008 builds on Mac OS 8.6, NT 4.0 SP5; unsure how to do a 
plaintext copy on RH Linux 6.0/GNOME.

Holding on formal verification to ask Akkana a question.

Comment 16

[Eli Goldberg]

Verifying as fixed. Will open separate bug on Monday for the missing spaces 
between table columns (as discussed with Akkana).

Comment 17

[Eli Goldberg]

<Wrote up bug #31994, for a regression in the pop-up select menu's text once 
again being picked up by the plaintext clipboard.>

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d7a7dde3627b
[fenix] Add tests for StartupReportFullyDrawn (https://github.com/mozilla-mobile/fenix/pull/12560)