Closed Bug 234576 Opened 20 years ago Closed 20 years ago

Autoscroll crashes (clicking middle-button/scroll wheel)


(Firefox :: General, defect, P2)

Windows XP





(Reporter: jwdawe, Assigned: bugs)



(Keywords: crash, regression)

Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040216 Firefox/0.8

When I middle-click, the Firefox crashes.

Reproducible: Always
Steps to Reproduce:
1. Middle Click anywhere on any page
Actual Results:  
Got the 'please tell Microsoft about this problem' dialog.

Expected Results:  
Not crashed.
This works for me 0.8+ 20040216 on Windows 2000, on two different computers with
3 button mice, could it be your mouse driver perhaps?
Sorry for the mistakes in the original post ("the Firefox" lol). I suppose it
could be my mouse driver, but I don't remember explicitly installing a mouse
driver. I'm using a Microsoft Wheelmouse Optical on Windows XP.  If anything, I
may have installed a driver from Microsoft's site.  And -- this behaviour did
not occur in 20040214 or the original 0.8 (or 0.7) builds.  This leads me to
believe that something added to Firefox in the last few days has caused this --
I have not made any changes to my computer, drivers, etc.
does this happen on a clean profile?  do you have any extensions installed
currently that might modify the middle mouse properties?
Same problem with a 20040218 build.

It didn't happen in v0.8, I just checked.
*** Bug 234705 has been marked as a duplicate of this bug. ***
The bug that i just duped to this one is also about crashing with a Microsoft
wheelmouse optical on Windows XP. Anyone with this mouse not crashing?
Keywords: crash, regression
Summary: Crashes on Middle-Click → Crashes on clicking middle-button/scroll wheel
After creating a new profile, the bug disappears. However when logging in to the
OLD profile the bug comes back. The bug remains present when logging into a new
profile after going back to the original one. After creating a third profile,
the bug was still present.  In other words the middle click worked properly
immediatly after creating a second profile, but then returned after switching
profiles after that.

This crash is still present in build 20040218.

The crash only occurs when clicking on text or a blank area of the page. If you
click on a LINK then it opens a new tab. (as expected)
Summary: Crashes on clicking middle-button/scroll wheel → Autoscroll crashes (clicking middle-button/scroll wheel)
Same here: Firefox crashes on WinXP Pro SP1, MS scrolling optical mouse (USB via
USB to PS2 adapter), MS IntelliMouse driver.
Works just fine on Firebird 0.7
Confirming based on comemnts and dupe.
Ever confirmed: true
Crash also occurs for me on WinXP Pro SP1 with Logitech Mouseman Optical (using
default Windows drivers) under build 20040218.

I did have the Microsoft Intellipoint software still installed from a previous
mouse, but uninstalling the software and rebooting did not fix this.  Did not
occur on 0.8
It would be interesting when this regression first appeared...
This one occured for me as well, I think in a 20040218 build. My mouse is not
optical; its a generic USB ball mouse. Going back to the 0.8 release fixed it.
None of my extensions change my middle-click functionality, by the way.
Not sure whether it matters, but this does not occur for me on the official
Linux XFT+GTK2 build for the 20th.
This bug occurs for me under Windows 98SE using:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20040219 Firefox/0.8
This bug started happening to me after I installed the trunk build the day
FireFox 0.8 was released. I didn't report it because I figured it was just a
problem with me not deleting my old profile when I installed. I have turned off
auto-scrolling and it no longer crashes.

It sounds like deleting your old profile will fix this problem, so is it really
a bug?
Agreed, I don't think it's within the scope of firefox programmers' duties to
ensure that old profiles don't crash new builds.
I used the installer version of 20040218 and got the error. 0.8 installer was OK.

Windows XP home edition.
-> me, I have a debug installer build. 
Assignee: firefox → bugs
Priority: -- → P2
Target Milestone: --- → Firefox0.9
(In reply to comment #17)
> I used the installer version of 20040218 and got the error. 0.8 installer was OK.
> Windows XP home edition.
Woke up this morning and realised missed a few important details - sorry!

After getting the error with 20040218, deleted old profile and reran installer.
Before adding themes or extensions error was still present.
It's been happening to me for a while now. Maybe now the problem is just getting
greater exposure due to changes in code. Actually, such crash is the only crash
that brings FF down. The place where it happens to me is on Blogupdates website
( It doesn't happen all the time -
only when certain conditions come to play together.
How to reproduce:
- on the page above, hover over the right column to get blog summary up
- middle-click on one of the links in the popup to open that blog entry in the
background tab
- while the new tab is loading, begin scrolling page with mouse wheel
- it might take opening several new links in new tabs for the crash to occur

The workaround that works for me 100% is to make popup blog summary go away and
only then begin scrolling.

System: WinXPPro sp1 fully patched, M$ default mouse driver + FF 0.8(FB 0.7
before). I have several extensions now. That extensions set varied with time,
but the crash is still there.
In 20040224 Installer build, I get the problem. In 20040225 *zip* build, there's
no problem. So it's just an installer issue?
Flags: blocking0.9+
I can't reproduce this when I install the win98 2004-02-26-08 build cleanly (in
an empty directory).

I installed the 2004-02-26-08 build in my 0.8 folder; the bug then became

Solution: Unzip/Install new builds into an *empty* directory!

I'm confirming what David said.

I installed 20040226 via installer and the bug is still present. Then I
uninstalled Firefox, deleted the old Firefox folders, and deleted C:\Documents
and Settings\Jason\Application Data\Phoenix.  Then I reinstalled with a zip
build, and could not reproduce the bug. Once again I deleted everything and this
time installed with an INSTALLER build, and could not reproduce the bug. Thus,
it is possible to install with the installer and not get this bug.

I will install tomorrow's nightly on top of the clean install I made today, and
see if the bug resurfaces or not.
from the comments in this bug, it looks like the problem really lies with
installing over top of 0.8.  This seems to be fallout from the greprefs landing.
 If we had Clean Install in the installer, this wouldn't be an issue.

Can anyone install into a new directory and still reproduce the bug?
Flags: blocking0.9+ → blocking0.9?
QA Contact: mconnor
I had the same problem with the nightly build of .7 the day before .8 was
released(the other nightly I had from a few weeks prior I don't believe had this
problem). I didn't file a bug report because the next day v.8 was out and the
problem wasn't there. However I just upgraded to the lastest nightly (2-28) and
this has happened again. It doesn't crash for me however if I middle click on a
link. I haven't tried deleteing my default profile however I did create a new
one and it didn't help, same problem happens on that one as well. I will try
doing a clean install as suggested towards the end of this tread and see if it
still occurs.
After wiping everything Mozillaish from my hard drive, and then installing Feb
26th build, and then installing the Feb 28th build on top of it, the bug has NOT
By the time the 1.0 release comes out, the end user should be able to upgrade
their version easily and WITHOUT breaking their profile -- and without it
causing bugs like this.
Otherwise, this bug appears fixed/invalid.
I concur that the problem does not exist if installed to a clean folder. I'll
leave it up to Ben to decide how to resolve this bug.
Although people who have .8 won't be happy if they have to jump through hoops
(delete Firefox folder) to install .9. By the time .9 is out, this should be
handled behind-the-scenes. (Or if Clean Install returns...)
This is the reason Clean Install is needed, because bugs result otherwise.  
Hopefully the whole "heuristic method" stuff gets implemented soon.

I'll resolve this at some point, but leaving open to catch dupes.
It's true!!!
If this is clean install related, INVALID. Look for bugs on clean install, or
file one ;-) 
Closed: 20 years ago
Resolution: --- → INVALID
Removing blocking0.9? since Ben invalidated this.
Flags: blocking0.9?
My comment #20 is actually bug #207781
You need to log in before you can comment on or make changes to this bug.