Crash when trying to drag "Customize Toolbar" sheet




12 years ago
12 years ago


(Reporter: abillings, Unassigned)




Firefox Tracking Flags

(Not tracked)




12 years ago

Comment 1

12 years ago
When a user moves the customize window for customizing toolbars, Firefox will crash.

This was found in:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/200707030404 Minefield/3.0a7pre

It does not reproduce in Windows.

1. Go to "View" - "Toolbars" and choose "Customize"
2. When the customize window comes up, it will be missing the top portion of the window (where it says "customize" normally).
3. Drag the customization window

Result: Crash.

Comment 2

12 years ago
(I guess it doesn't say "Customize" on the Mac but dragging the window still crashes.)

Comment 3

12 years ago
I'm pretty sure this is called a "sheet" on Mac. It's not meant to be dragged, but rather attached to the window.

Once we get a non-blank Breakpad ID we should post it here.
Keywords: pp, stackwanted
Summary: Dragging "Customize" window for customizing toolbars crashes → Crash when trying to drag "Customize Toolbar" sheet

Comment 4

12 years ago
You're probably right which makes it all the more fun that if I try to drag it, it does crash. :-)

On Windows it is a dialog but I'm not too hip to Mac terminology and some of the UI standards there.
I can't drag it, or crash trying, either one. Is there either a step 0 (go to a particular page, maybe?), a step 2.1 (after the fake-sheet comes up, do foo), or a step 2.5 (what part of the sheet are you grabbing, with what sort of gesture, using what sort of pointing device?) that I'm missing?

Comment 6

12 years ago
Nope. It's as simple as bringing up the browser and then immediately customizing. Marcia was able to repro it as well. We were both using the current trunk build from last night on Macs.

I'm clicking near the top of the sheet and dragging up normally but it was pretty easy to do and I didn't have to do anything tricky.

Comment 7

12 years ago
This was fixed by a checkin by on Tuesday night. I have verified that it is fixed now.
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 8

12 years ago
Marking verified. Verified in:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/200707050404 Minefield/3.0a7pre
Al, please can you quote the bug number for future reference.
Keywords: stackwanted

Comment 10

12 years ago
Looks like it was the check-in for bug 386751.

Also, it's usually not good style to verify bugs that one has resolved themselves. I guess the normal workflow would be that a developer checks in a patch and marks as FIXED, then someone marks as VERIFIED FIXED when they verify that the patch actually fixed the bug. Another example would be if someone resolves a bug as WORKSFORME and another person comes behind and marks VERIFIED WORKSFORME when they cannot reproduce either. Not that this is actually documented anywhere... it's just what normally happens in practice.
Depends on: 386751

Comment 11

12 years ago
I'm aware of good style but I asked the rest of the QA org and they said to go ahead and resolve and verify it. No one else wanted to do it. :-)

Marcia had a verbal conversation with Josh where he said that he'd fixed it with a checkin on Tuesday but no details were given as to what bug it was originally for. She verified the fix (as did I) in subsequent builds. He said that this bug was a known issue (to him).

Since Josh didn't mark this as fixed, I conferred with Marcia and Tchung and they said to just go ahead and resolve and verify this since it would lurk out there otherwise until someone else did it.
You need to log in before you can comment on or make changes to this bug.