Closed Bug 35899 Opened 24 years ago Closed 24 years ago

Page scrolls on selecting text in position:relative div

Categories

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

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: jrspm, Assigned: kinmoz)

References

()

Details

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

Attachments

(5 files)

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
In Linux Build 2000041412, I'm not seeing the blank spot that you mentioned on
the page.  Did you happen to save a copy?
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
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.
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?
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.

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.

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
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. 
assigned to me
Assignee: troy → buster
Status: ASSIGNED → NEW
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: crashnsbeta2
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
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
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.
Whiteboard: davidr8@home.com simplifying
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]
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
I have seen this on linux too. See bug 39201.
*** Bug 39201 has been marked as a duplicate of this bug. ***
Target Milestone: --- → M16
removed testcase keyword since there is a test case for this bug
Keywords: testcase
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
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]
I'll take this one from mjudge.
Assignee: mjudge → kin
Status: ASSIGNED → NEW
Accepting bug.
Status: NEW → ASSIGNED
Attached file very simple testcase
Could bug 33226 be related?
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.
*** Bug 42133 has been marked as a duplicate of this bug. ***
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
*** Bug 43149 has been marked as a duplicate of this bug. ***
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
setting to nsbeta3+
Whiteboard: nsbeta3+
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]
setting priority in status whiteboard
Severity: major → critical
Priority: P3 → P1
Whiteboard: [nsbeta3+] → [nsbeta3+][p:1]
I have a fix for this in hand. r=jfrancis@netscape.com
Whiteboard: [nsbeta3+][p:1] → [nsbeta3+][p:1][Fix in hand]
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
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta3+][p:1][Fix in hand] → [nsbeta3+][p:1]
Marking verified in the Sept 7th builds.
Status: RESOLVED → VERIFIED
*** 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.

Attachment

General

Created:
Updated:
Size: