65141 - Selection highlighting disappears on mouse up when selecting link text in Composer

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Charles Manske]

Bring up any page in Composer with a link or create a link in a page.
Click inside the link and drag mouse to select the text -- drag to text that is
not part of the link.
When mouse is released, the selection highlighting disappears in the link text,
but is ok in non-link text.
The problem seems to be triggered by the change in link color that happens
between the "active" (mouse down) and "normal" (mouse up). The redraw of link
text doesn't pay attention to the selection state of the text.
If CSS rules are used that make the normal and active states the same color,
this bug doesn't occur.
The selection still does contain the link text, so this problem is very
confusing to the user and causes loss of data since any typing action will
delete the selection, including that in the link.
(This bug would exist in Browser if we didn't jump to a link that we click on.)

Comment 1

[Marc Attinasi]

One thing Charley and I discussed was moving the rule for :link:active out of
ua.css and into the pref stylesheet, so that it gets disabled along with the
rest of the prefs in Composer. This would probably fix much of this problem, but
there may be a more subtle bug underlying the loss of the selection that it will
merely mask. Specifically, I am wondering why a selected frame is not showing up
as selected when it is redrawn, even though it's selection state has not
changed? CC'ing mjudge for his input on this.

Comment 2

[Marc Attinasi]

Assigning milestone

Comment 3

[Charles Manske]

Changing milestone to 0.9.1. I believe this is a very important issues and should
be fixed in time for NS 6.5.
Can we at least explore moving :link:active as Marc suggests?

Comment 4

[Marc Attinasi]

Attachment: Testcase showing that the problem does not happen in browser

Comment 5

[Marc Attinasi]

In the test case I just attached, selecting the link and then activating it does
NOT cause the selection to disappear. There is something else happening here,
probably having to do with how the editor handles links (what does the editor do
to prevent links from being navigated?).

Comment 6

[Charles Manske]

This is the cause of the disappearing selection in link text:
in EditorOverride.css:

a:visited, a:active, a[name], a:link img, a:visited img {
  -moz-user-input: none;
}

Removing just "a:active" fixes the bug.
I have a question, though: Why should an "a:active" repaint be triggered when
you *start* the drag inside a link, and end it outside the link (conditions for
the bug), and not when you start outside and drag-select into the link text?
The bug also doesn't show if start and end of drag selection is within the link
text.
I thought the purpose of "-moz-user-input: none;" was to suppress following
links, but it isn't. I'm not sure why we have that rule for a:visited, a:active
Anyone else know?

Comment 7

[Marc Attinasi]

>I have a question, though: Why should an "a:active" repaint be triggered when
>you *start* the drag inside a link, and end it outside the link (conditions for
>the bug), and not when you start outside and drag-select into the link text?

I think it is because the mouse-down in the link is what makes it active and 
thus triggers the :active rule and the resultant visual restyle. Starting 
outside of the link does not activate the link, so it never triggers the :active 
rule.

So Charley, do you want to fix this in the EditorOverride stylesheet?

Comment 8

[Charles Manske]

This does seem to be the right fix, though I'll need to search through checkin
logs to figure out why it was added in the first place!
It would help if someone already knew or could explain exactly what
"-moz-user-input: none" is supposed to do.

Comment 9

[Simon Fraser [no longer active]]

-moz-user-input is our version of CSS3's user-select style.

Comment 10

[Charles Manske]

Attachment: Don't use "-moz-user-input" for link text

Comment 11

[Charles Manske]

After reading the CSS3 spec, it seems clear we shouldn't be setting "user-select"
(aka "-moz-user-input") to none for link text.
ready to review

Comment 12

[kinmoz]

sr=[e-mail]

Comment 13

[Akkana Peck]

This seems to be an issue of specific keybindings; rather than morphing this
bug, I'm closing it and Sujay is going to file a new bug on the specific
regressions.

Comment 14

[Charles Manske]

Woa! I think you're in the wrong bug, akkana!

Comment 15

[Akkana Peck]

Wow, how'd that comment get in this bug?  Sorry!

Comment 16

[Charles Manske]

Removing sr, still need r=

Comment 17

[Marc Attinasi]

r=attinasi

Comment 18

[kinmoz]

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

Comment 19

[Simon Fraser [no longer active]]

r=sfraser

Comment 20

[Charles Manske]

checked in.

Comment 21

[Chris Petersen]

Marking verified in the May 21 build (2001052108).