Closed Bug 386785 Opened 18 years ago Closed 18 years ago

Crash when trying to drag "Customize Toolbar" sheet

Categories

(Firefox :: Toolbars and Customization, defect)

Product:
Firefox
Component:
Toolbars and Customization
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: abillings, Unassigned)

References

Details

(Keywords: platform-parity)

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. Steps: 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.
(I guess it doesn't say "Customize" on the Mac but dragging the window still crashes.)
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
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?
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.
This was fixed by a checkin by joshmoz@gmail.com on Tuesday night. I have verified that it is fixed now.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Marking verified. Verified in: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/200707050404 Minefield/3.0a7pre
Status: RESOLVED → VERIFIED
Al, please can you quote the bug number for future reference.
Keywords: stackwanted
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
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.