292581 - funky selection behaviour 3

Status: RESOLVED WORKSFORME

(Core :: DOM: Selection, defect)

Description

[Caleb]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050501 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050501 Firefox/1.0+

This one is hopefully the last selection bug i stumble onto.

The behaviour is kinda similar to bug 289792, but a bit less extreme.

Reproduction:

1. Open the specified URL
2. Look at the first post by 'ratboy2000'
3. Start selecting his post text from the bottom (starting from the 'Guess I'll
wait.' line) and upwards.

When your mouse pointer reaches a few milimeters above the first line of his
post the selection kinda inverts/jumps back. You can also try moving your mouse
when that happens and notice that the selection moves in a place different than
the one the mouse is pointing to.

I tried making a testcase, without any success, any help would be appreciated!

Reproducible: Always

Steps to Reproduce:

Comment 1

[Dimitrios]

didn't search for duplicates yet, but I can confirm this bug on FF 20050502.
Attaching an ultimately (hoping not too ultimately :) ) reduced  testcase. It
seems that the combination of the <H2> tag and the <div style="float:left;"> for
the main text triggers this bug.

To reproduce :
1. open the attached testcase
2. reduce browser window height (in order for the verical scrollbar to appear)
3. Try to select the entirety of the main 
text from an arbitrary line. E.g. starting from the first line and moving
downwards until you hit the status area.

Result: When the cursor hits the status area of the browser window, it starts
scrolling (as expected) BUT the selected text changes to something on the left
or top of the initial selection starting point.

Comment 2

[Dimitrios]

Attachment: reduced testcase

Comment 3

[Thomas K. (:tom)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050419
Firefox/1.0.4

Happens here, I scroll down and the selection flips and then back and flips
again, rather odd, just like described.

Adding clean-report based on what Dimitrios said.  Also, I wouldn't know what to
dupe this too, so not even gonna try.

Comment 4

[Hermann Schwab]

Attachment: original testcase ?

table in a float:left div, reduced, but not minimized.

Comment 5

[Caleb]

Requesting blocking since this bug makes it difficult to select text in some
circumstances.

Comment 6

[Caleb]

I'm not 100% this is related, but here's another page that has really poor
selection behaviour:

http://www.allmusic.com/cg/amg.dll?p=amg&searchlink=FOUR|FRESHMEN&uid=MIW060505271437&sql=11:7x6fmpb39f5o~T2

Try to select "The Four Freshmen" while dragging the mouse from right to left
and moving it across the center of the letters.. the selection will suddenly
move to the "wrong person? more matches HERE" link. Although if you hold your
mouse really high (practicly above the text) the selection won't screw up.

I'll try to get a minimized testcase sometime soon, but this makes selecting
very annoying.

Comment 7

[Eli Friedman]

Attachment: Very simplified testcase

This is definitely a regression from Firefox 1.0, although I have no idea when
it regressed.

Comment 8

[Asa Dotzler [:asa]]

Eli, can you look through the builds at archive.mozilla.org and try to determine
when this regressed? that would help us a lot.

Comment 9

[Eli Friedman]

This regressed between the April 14 and April 15 builds.  Looking at Bonsai, it
seems most likely this was regressed by Bug 289792 (how ironic).

Comment 10

[Eli Friedman]

Attachment: Patch v1

I edited this patch because I have other changes in my tree, so it might not
apply cleanly.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So why does that patch work?

Comment 12

[Eli Friedman]

Attachment: Better testcase to understand the issue

The problem was that event coordinates were not being translated at the right
time.  The previous code was passing coordinates relative to the frame's view
instead of relative to the frame's parent view.  Therefore, the frame was
misinterpreting the coordinates it recieved.

This is all really wacky, and I think I'm going to make this use frame
coordinates sometime in the 1.9 cycle.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 190089 [details] [diff] [review]
Patch v1

r+sr=bzbarsky.	I hate GetOffsetFromView...

Comment 14

[Caleb]

Attachment: Patch v1 (unbitrotted)

I've tested this patch, it works well (thank Eli!).

Comment 15

[:Gavin Sharp [email: [e-mail]]]

Checking in nsFrame.cpp;
/cvsroot/mozilla/layout/generic/nsFrame.cpp,v  <--  nsFrame.cpp
new revision: 3.570; previous revision: 3.569
done

Comment 16

[Eli Friedman]

Could someone back out this patch?

Comment 17

[:Gavin Sharp [email: [e-mail]]]

I can back it out... but why? Care to explain?

Comment 18

[:Gavin Sharp [email: [e-mail]]]

Ah, nevermind, someone on stephend was kind enough to point out bug 302804. I
backed it out.

Checking in nsFrame.cpp;
/cvsroot/mozilla/layout/generic/nsFrame.cpp,v  <--  nsFrame.cpp
new revision: 3.574; previous revision: 3.573
done

Comment 19

[Caleb]

This was fixed by bug 296036.