180015 - [FIX] {drag-select} Scrolling by selecting & dragging jumps to top of page when marquee tag is encountered

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect)

Description

[Dan Soper]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; es-ES; m18) Gecko/20010131 Netscape6/6.01
Build Identifier: Mozilla 1.0.1 build 2002082606

When selecting text in any page that contains a < marquee >, when the selection
reaches that marquee the browser immediately jumps to the top of the page.

Reproducible: Always

Steps to Reproduce:
1. Find a page which uses the Marquee tag.
2. Click on text in the page and drag downwards ot select.
3. Continue to drag below the bottom of the browser window, so the page scrolls
downward as the selection grows.


Actual Results:  
When the selection reaches the marquee, the page jumps right back up to the top.

Expected Results:  
Keep on scrolling (and selecting) downwards.

Reproducibility: doesn't happen *every* time, but very nearly.

Comment 1

[Dan Soper]

My browser User-Agent ain't what it says in that report, btw. :-)

Comment 2

[Dan Soper]

For how long should a bug be "unconfirmed" before the reporter (me) is entitled
to think it's been ignored or overlooked?

Whatever, shortly after posting the bug I discovered how to switch off the
marquee tag by adding:

     marquee { -moz-binding: none; }

to UserContent.css, which I immediately did.

Comment 3

[José Jeria]

How about attaching a testcase?

Comment 4

[Dan Soper]

Attachment: Test case

Apologies for the delay.

Attaching a simple html page in which the bug may be observed: Select text in
the page, and drag downwards so the page scrolls. The text "Scrolling text..."
is in the marquee tag, so when you've scrolled down that far, position your
mouse such that the marquee text is partly selected. Hold the mouse still at
this point, and wait for the marquee to scroll around again. As soon as the
beginning of the marquee text reaches your mouse pointer, the page jumps up to
the top, as described in my original report. If nothing happens, a slight
movement of the mouse might be necessary.

I have found this bug is also present in Phoenix.

Comment 5

[Rainer Bielefeld]

I still see this in
Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.4b) Gecko/20030502

Comment 6

[Mats Palmgren (inactive)]

Bug also occurs in Linux trunk build 2004-07-23-06. Steps to reproduce:
load testcase, scroll to end, click on the last text and drag upwards, when
you reach the marquee - move the mouse to the *right* of it.

Comment 7

[Mats Palmgren (inactive)]

Drag-selection in the testcases for bug 97283 and bug 56602 also triggers
the same bug and results in "impossible" selection regions sometimes.
Taking bug as I have a fix for this...

Comment 8

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

When dispatching the event to a new frame we must translate the event position
the new frame's closest view (when different).

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 154304 [details] [diff] [review]
Patch rev. 1

r=bzbarsky

Comment 10

[Martijn Wargers (dead)]

Is there a reason this patch hasn't been checked in?

Comment 11

[Martijn Wargers (dead)]

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

Comment 12

[Martijn Wargers (dead)]

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

Comment 13

[Martijn Wargers (dead)]

There might be a good reason why this patch (which has review+ and
supperreview+) never got checked in, but it could also be that this patch simply
is forgotten, not?
So if soemone could confirm there is a reason other than that is forgotten, then
I won't "harass" this bug again.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This should still be landed, as far as I can tell.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Though at this point I'd prefer it be modified to use nsIView::GetOffsetTo.

Comment 16

[Mats Palmgren (inactive)]

Attachment: Patch rev. 2 (using nsIView::GetOffsetTo)

(In reply to comment #10)
> Is there a reason this patch hasn't been checked in?

Well, I started looking at bug 253076, and then I looked a bit at this "mouse
capturer thing" and the translations for that... thinking that that does not
belong in frame code but in the view/event manager perhaps and that someone
should look broader at this event origin problem...
... and only then I forgot about the whole thing ;-)

Comment 17

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 168086 [details] [diff] [review]
Patch rev. 2 (using nsIView::GetOffsetTo)

r+sr=bzbarsky, though the closestView != resultFrameView check is redundant,
imo, and the null-check on resultFrameView is also somewhat redundant (can it
ever be null?  I don't believe so).

Comment 18

[Stephen Donner [:stephend] Not actively reading bugmail]

Isn't this ready to be landed?

Comment 19

[Mats Palmgren (inactive)]

It was checked in before your comment ;-)  I waiting for Tinderbox...

Comment 20

[Mats Palmgren (inactive)]

Checked in 2005-01-16 10:10 PDT

-> FIXED