Page scrolls on selecting text in position:relative div

VERIFIED FIXED in M18

Status

()

Core
Selection
P1
critical
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Jacob Kjome, Assigned: kinmoz)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+][p:1], URL)

Attachments

(5 attachments)

(Reporter)

Description

18 years ago
I tested this in both yesterdays build and confirmed the same thing in today's 
build (2000041409).

What one should expect:
the user can click anywhere within the document and expect that the browser 
will no spontaneously exit


what actualy happens:
Clicking on a specific part of th document (that isn't even a link) causes the 
browser to exit unexpectedly


To reproduce:
1. Load the page

2. scroll down to the "More Coverage" image just a bit above the "Sound Off" 
section

3. Notice to the right of "More Coverage" that there is a sentence "The digital 
gaffe initially was discovered by a Europe-based employee" then there is a 
blank line and then part of the previous sentence is repeated again (which may 
be another bug all in itself)

4. Click on the blank line between the quoted sentence and its partially 
repeated copy below that.

5. This browser window and all other open mozilla browser windows should have 
just exited without warning.


Just a couple other notes:
1. There is a bunch of blue text that begins with a header enclosed in <span> 
tags with a css class name given to it: "Almost every Web-hosting provider".  I 
don't believe the text should be all blue, just the header.  IE5 renders the 
text after this header in the normal black colored text as it should.

2. Clicking near the area that causes the sudden browser exit does some other 
things.  It causes the browser to scroll down unexpectedly.  


I would create a simplified test case for this, but I have NO idea why it is 
happening.

Jake

Comment 1

18 years ago
In Linux Build 2000041412, I'm not seeing the blank spot that you mentioned on
the page.  Did you happen to save a copy?

Comment 2

18 years ago
Confirmed exactly as reported with the 2000-04-14-09-M16 nightly binary on 
WinNT. Mozilla died so quickly that talkback did not notice.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash

Comment 3

18 years ago
Created attachment 7605 [details]
Page as saved by Mozilla; crashes like live URL

Comment 4

18 years ago
The saved page shows the same stutter in the layout as the live page.
This is a very reproducible crash.

A possibly-relevant detail: NN4.72 shows only the first two paragraphs in a 
sans-serif font, but Mozilla shows several more from the middle to the end of 
the story in the same font and colour as the first paragraph.

Comment 5

18 years ago
I'm sorry - I still don't see this with Linux Build ID 2000041412 (even on
attachment).  I tried clicking all around the area described, and couldn't get
anything to happen...anyone else having trouble reproducing?

Comment 6

18 years ago
Mine crashes in GDI.EXE as I scroll down on that page, right as the "More 
Coverage" image starts to show.  2000 041409 on Win 98.

Comment 7

18 years ago
Mine crashes in GDI.EXE as I scroll down on that page, right as the "More 
Coverage" image starts to show.  2000 041409 on Win 98.

Comment 8

18 years ago
I can't reproduce the clicking problem either, but I'm also hitting an assert 
the text frame code which in turn triggers an assert in the view manager code 
about recursive painting
Status: NEW → ASSIGNED

Comment 9

18 years ago
This is an odd one. The repeat and blank area do not show up in the page as
rendered by the 2000-04-17-08-M16 nightly binary on WinNT, but do in an
04-15 build, which also crashes. The crash is looking WORKSFORME now.

What is puzzling is that the quoted sentence looks fine in the original 
raw HTML, but clearly part of it including the <A> element was not painting:
 > The digital gaffe initially was discovered by a Europe-based employee of 
 > ClientLogic Corp. (<a 
 > href="http://www.clientlogic.com/">www.clientlogic.com</a>) of Nashville, 
 > Tenn., which sells e-commerce technology. 

Comment 10

18 years ago
assigned to me
Assignee: troy → buster
Status: ASSIGNED → NEW

Comment 11

18 years ago
the original problem is WorksForMe.  However, I do get odd selection and 
scrolling behavior when I click at random-seeming spots in this document.  
Scroll the document down to "One of the experts who helped..." and click on that 
paragraph.  You'll see the document scroll to a random-seeming part of the 
document, and an odd portion of the document is selected.  

Changing summary.  removing crash keyword.  nominating for nsbeta2.  changing 
component to selection.  assigning to mjudge.
Assignee: buster → mjudge
Component: Layout → Selection
Keywords: crash → nsbeta2
Summary: Mysterious browser exit caused by clicking on certain spot in browser document → Mysterious selection and scrolling behavior caused by clicking on certain spot in browser document

Comment 12

18 years ago
I'm going to try to simplify the page for the selection problem.

There's another bug visible on this page: scroll around for a bit (maybe select 
some text), and every once in a while mozilla will eat 5 seconds of cpu, making 
mozilla AND other windows apps unresponsive.
Whiteboard: davidr8@home.com simplifying

Comment 13

18 years ago
Created attachment 8415 [details]
Test case: select text below the first screenful, page scrolls

Comment 14

18 years ago
The phenomenon with the page scrolling after clicking (as opposed to 
dragging/selecting) text only seems to happen if I hold the mouse button down 
for half a second or move the mouse a little bit.  I suggest that the clicking 
bug be ignored until the dragging bug be fixed, because it seems likely to go 
away.

I split off several other bugs that were showing up on the page:

Bug 38515, which was causing: too much text is blue
Bug 38516, which was causing: one paragraph is unselectable

It's getting late, so I'll simplify the freezes tomorrow unless someone else 
does it.

Comment 15

18 years ago
Created attachment 8421 [details]
*partially* simplified page that shows freezes

Updated

18 years ago
Whiteboard: davidr8@home.com simplifying

Comment 16

18 years ago
Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.
Whiteboard: [nsbeta2+][6/01]

Comment 17

18 years ago
Reducing severity from critical to major because this no longer crashes.

Some more bugs that show up on the original zdnet page:
Bug 12764 causes: clicking without dragging can cause scrolling
Bug 35971 causes: if you hold long enough on the text for it to scroll all the 
way to the bottom, the scrollbar becomes unusable until you click on text
Bug 38643 causes: local copy of page (or third testcase) freezes occasionally

To clarify, this bug is about mozilla scrolling the entire page when a small 
amount of text is selected inside a position:relative div, and the test case 
that goes with this bug is the second attachment.
Severity: critical → major
Keywords: testcase
Summary: Mysterious selection and scrolling behavior caused by clicking on certain spot in browser document → Page scrolls on selecting text in position:relative div

Comment 18

18 years ago
I have seen this on linux too. See bug 39201.

Comment 19

18 years ago
*** Bug 39201 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Target Milestone: --- → M16

Comment 20

18 years ago
removed testcase keyword since there is a test case for this bug
Keywords: testcase

Comment 21

18 years ago
this is real hard to debug. i cant tell what part of the system is lying to me.  
The mouse event is sent to me as a point relative to some view that doesnt make 
sense...
Status: NEW → ASSIGNED

Comment 22

18 years ago
Due to slip in schedule, moving this bug from [6/01] to [Will be minus on 6/15] 
for fix deadline.
Whiteboard: [nsbeta2+][6/01] → [nsbeta2+][Will be minus on 6/15]
(Assignee)

Comment 23

18 years ago
I'll take this one from mjudge.
Assignee: mjudge → kin
Status: ASSIGNED → NEW
(Assignee)

Comment 24

18 years ago
Accepting bug.
Status: NEW → ASSIGNED

Comment 25

18 years ago
Created attachment 9755 [details]
very simple testcase

Comment 26

18 years ago
Created attachment 9756 [details]
shows that scrolling is faster with nested DIVs

Comment 27

18 years ago
Could bug 33226 be related?
(Assignee)

Comment 28

18 years ago
I've taken a look at the click causes scroll problem, and it looks like it's due 
to the fact that the autoscroll code is out of date. Things have changed 
significantly in terms of event dispatch to frames and event capturing since I 
wrote it.

I'm in the process of rewriting nsDOMSelection::DoAutoScroll() to account for 
the changes, and it works much better in my source tree. Still working out some 
little kinks though.

Comment 29

18 years ago
*** Bug 42133 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 30

18 years ago
Removed nsbeta2 keyword as per beppe. We shouldn't hold up nsbeta2 for this bug, 
but it definitely needs to be fixed before RTM.

Moving bug to M17, where I hope to get back to working on it.
Keywords: nsbeta2
Whiteboard: [nsbeta2+][Will be minus on 6/15]
Target Milestone: M16 → M17

Comment 31

18 years ago
*** Bug 43149 has been marked as a duplicate of this bug. ***

Comment 32

18 years ago
autoscroll code needs to be re-written because event dispatching and capturing 
has changed, if this is not done there is the potential for unexpected scrolling 
behavior to random places in the document
Keywords: correctness, nsbeta3
Target Milestone: M17 → M18

Comment 33

18 years ago
setting to nsbeta3+
Whiteboard: nsbeta3+

Comment 34

18 years ago
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]

Comment 35

18 years ago
setting priority in status whiteboard
Severity: major → critical
Priority: P3 → P1
Whiteboard: [nsbeta3+] → [nsbeta3+][p:1]
(Assignee)

Comment 36

18 years ago
I have a fix for this in hand. r=jfrancis@netscape.com
Whiteboard: [nsbeta3+][p:1] → [nsbeta3+][p:1][Fix in hand]
(Assignee)

Comment 37

18 years ago
Fix checked into:

  mozilla/layout/base/src/nsSelection.cpp  revision 3.64

Rewrote auto-scrolling code to handle the fact that events are now
passed directly to frames, even though the mouse is outside the
window, and the frame is not in the clip view. The old code assumed
that the viewport frame always caught and handled the event, which
was the way it used to be.

r=jfrancis@netscape.com
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta3+][p:1][Fix in hand] → [nsbeta3+][p:1]

Comment 38

18 years ago
Marking verified in the Sept 7th builds.
Status: RESOLVED → VERIFIED

Comment 39

18 years ago
*** Bug 52247 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.