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.

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

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

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.

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.

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.

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

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.

I have seen this on linux too. See bug 39201.

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

removed testcase keyword since there is a test case for this bug

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

Due to slip in schedule, moving this bug from [6/01] to [Will be minus on 6/15] for fix deadline.

I'll take this one from mjudge.

Accepting bug.

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.

*** 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

setting to nsbeta3+

adding the brackets in the status

setting priority in status whiteboard

I have a fix for this in hand. r=jfrancis@netscape.com

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

Marking verified in the Sept 7th builds.

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