13093 - Don't change cursor or do mouseovers during selection

Status: RESOLVED FIXED

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

Description

[Michael Lowe]

During selection of some text if you move the mouse over a hyperlink the cursor
changes from the I-beam to the pointing-hand.   Instead, it should always stay
as an I-beam.

Comment 1

[Eli Goldberg]

Confirmed that this is a cross-platform issue, and also present on Mac OS &
Linux; adjusted platforms correspondingly. Thanks, Michael!

Comment 2

[Michael Lowe]

I also noticed that the cursor currently changes to a normal pointer when it is
not over any text.   I think what should happen is that once the mouse is down
the cursor changes to an I-beam and stays that way no matter what it is over
until the mouse is back up again.

Comment 3

[Eli Goldberg]

Agreed 100%; that's probably a side-effect of the fact that selection currently
doesn't work in dead spaces (without text).

Comment 4

[mjudge]

another bounced to the manske man.

Comment 5

[Charles Manske]

*** This bug has been marked as a duplicate of 10236 ***

Comment 6

[Michael Lowe]

Is this really a duplicate?   bug 10236 deals only with the cursor over
hyperlinks in the editor.  This bug deals with the cursor while selecting text
in the browser or the editor, which seems a different problem.   Also read
comment from [09/03/99 14:15]

Comment 7

[Charles Manske]

It doesn't matter if you are in the act of selecting or not. The cursor is
controlled by CSS in both cases. So bug 10236, which is fixed, covers the
editor case, which should never use the "pointer" hand cursor.
So if you don't want the pointer when selecting in the browser, that is a
different bug. I don't think CSS can respond differently during selecting,
i.e., when the mouse is being dragged.
Peter: Is that possible?

Comment 8

[Peter Linss]

No, CSS has no notion of "dragging" state to select against. This seems like the
code looking for different cursors should just not do anything during a drag
select... (all in event state manager?)

Comment 9

[Charles Manske]

So it seems the selection code will have to communicate with the style system
to control this and the related problem in bug 12523, where the cursor is
changing to inappropriate types and cannot be defeated with CSS settings.
Sorry, Mike, but these problems will have to be solved in the selection/pres.
shell code, not in our CSS files.

Comment 10

[sujay]

still happening in 9/17 build....Charley wanted me to verify if its working...

Comment 11

[Michael Lowe]

One more related bug.   During selection, when the mouse is over a button or
anything else where the hover style is set, the hover style should not be
painted in this case.

Comment 12

[Charles Manske]

I added "in browser" to summary to remind us that this is not a problem in
the editor because we override the "pointer" cursor over links.

Comment 13

[Michael Lowe]

Another related bug.   During selection, when the mouse is over something where
JavaScript on-mouse-over or similar event handlers have been set, the JavaScript
handlers should not be called.

Comment 14

[Michael Lowe]

Actually, this is a problem in both the editor and browser.   In the editor,
this has been fixed for links, but it is still a problem in whitespace
(areas containing no text) where the cursor changes back to an arrow during
selection.   Other parts of this bug such as diabling hover style and JavaScript
events also apply.

Comment 15

[Michael Lowe]

This bug is closely related to bug 15030 and vice versa.

Comment 16

[rubydoo123]

changing status to assigned, keeping this at m15, it can wiat till after beta
push

Comment 17

[Kathleen :Brade]

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

Comment 18

[Eli Goldberg]

[Note to self: please verify 15030 when verifying this bug.]

Comment 19

[rubydoo123]

moving to M17

Comment 20

[mjudge]

per beppe moving to polish

Comment 21

[mjudge]

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

Comment 22

[mjudge]

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

Comment 23

[rubydoo123]

moving this to future and adding helpwanted keyword

Comment 24

[Blake Ross]

*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
[e-mail] to [e-mail].  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...

Comment 25

[Matthew T (active 1999-2002)]

[Resummarizing]

Comment 26

[Blake Ross]

changing selection qa to tpreston.

Comment 27

[John Keiser (jkeiser)]

It seems to me that the cursor should become an arrow to indicate that the
selection is draggable (you can drag/copy/paste).  However, if you do
:-moz-selection { cursor: normal } selection becomes utterly impossible, so this
rule is hard to enforce.

Comment 28

[Peter Kroll]

still happening in build:
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.5) Gecko/20030925

Comment 29

[Justin Wood (:Callek)]

the ::-moz-selection { cursor: something; }  bug is really the issue found in
Bug 231894, which has a patch (by me) pending review.

Comment 30

[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.

Comment 31

[Sean Feng [:sefeng]]

This seems can be fixed by adding some checks to nsTextFrame::GetCursor to
see if (GetFrameSelection()->GetDragState() && GetContent()->AsElement()->IsLink() && (PreviousCursorIsText || PreviousCursorIsVerticalText) && NoUserProvidedStyleForLink) { return PreviousCursor; }

WDYT Emilio?

Comment 32

[Emilio Cobos Álvarez (:emilio)]

GetContent()->AsElement()->IsLink() would trivially crash because the content of text frames is a text node, but something along those lines might make sense. Couple notes:

• I don't think we want to look at the previous cursor, as it can be basically anything right? Plus even if you're not dragging the text cursor is an I-beam so...
• Is GetDragState enough / the right thing, so that it doesn't change the cursor on link dragging?
• We probably want to also do it if the cursor is pointer more generally, as it'd be weird that doing :link { cursor: pointer } would break this.

Chrome handles it here fwiw.

Comment 33

[Sean Feng [:sefeng]]

Attachment: Bug 13093 - Don't change cursor when mouseover links during selection r=emilio

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5c9aa60ea6f4
Don't change cursor when mouseover links during selection r=emilio

Comment 35

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/5c9aa60ea6f4