Closed Bug 115223 Opened 23 years ago Closed 22 years ago

sticky back history button

Categories

(Core :: XUL, defect)

PowerPC
Mac System 8.5
defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 102330

People

(Reporter: bingalls, Assigned: hyatt)

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.6+) Gecko/20011210 BuildID: 2001121008 The popup menu associated with the history for the back (as well as forward) button, sometimes doesn't unload, after losing focus. Worse, the menu is lowered, beneath the browser window, and is not visible. Ultimately, I begin to wonder why the keyboard in Mozilla isn't working; it's because all keyboard messages go to the history popup, even while mouse messages, such as moving the scrollbar, go to the main window. Reproducible: Couldn't Reproduce Expected Results: Moving the mouse off the menu should not destroy it. However, clicking the mouse anywhere else, should destroy all popup menus.
Bruce, please provide Steps to Reproduce this problem.
I finally figured out how to make this reproducible. Generate some history Click on the back button dropdown. Use the keyboard arrows to move to the middle of the dropdown. Click the mouse elsewhere The dropdown is now hidden (beneath the browser?) and it is hard to tell, but it still has the keyboard focus. It looks to the user, like Mozilla is not responding to the keyboard. Of course, Mozilla is responding, you just can't see where it is responding. Note that there is a similar problem with the context popup: double click in a nonactive area of a web page. This brings up the context popup. Click elsewhere, to try to dismiss the menu. Now, try to bring up the menu, again.
Fwiw, WorksForMe using Mac/2001112011 (0.9.6). I'll try a newer nightly.
Still WorksForMe using Mac/2001121308.
session history
Assignee: pchen → radha
Component: XP Apps → History: Session
QA Contact: sairuh → claudius
I found another way to reproduce this problem. I am using the Classic theme, if that makes a difference. Here goes: Generate some history. Move the mouse to the dropdown for the history list, next to the back button. Drag the mouse down to a selection. Release the mouse button. (Optional?) Do not move the mouse, as the back page loads. The down button remains shaded, and the keyboard feels like it has locked up, until either you click on the down button again, or hit 'esc'. Works just as badly for the Forward button.
This seems to be a duplicate of, or at least closely related to, bug 102330. The bad thing that happens (drop-down menu persists in background, stealing keyboard focus) is the same for both. For most people, this would be perceived as a crash, as the browser seems dead (i.e., keyboard doesn't work). This is serious, and exactly the sort of bug that keeps me from recommending Moz to my dad, and other bug-intolerant people. This happens to me frequently, though not all the time. Don't know why. Current version 0.9.9, though this has been going on at least since 0.9.8. Mac OS 9.2.2.
I can reproduce this problem most of the time. I thought it was all the time, but sometimes it works correctly, so maybe this is some kind of timing problem, being influenced by random circumstances. I'm using Mozilla Build 2002041008 on Mac OS 9.1 on an orange iBook with 300 Mhz G3 processor and 160 MB RAM. To reproduce: 1) Surf some pages 2) Click on the small part of the back (or forward) button that shows the windows history menu 3) Click on any item in the menu Result: Mozilla goes to the selected URL, but the back menu stays expanded. As the original report says, somtimes the menu is even covered by the browser window, which makes the bug even worse. The menu can be closed by clicking and releasing on the small back or forward menu button a second time, unless it has been disabled because the first/last item in the history list has been reached. Expected Result: The back history menu should disappear when an item in it is selected.
Something that is slightly different between the problem I'm having with the original report is that I only see that behaviour when I actually select an item from the back button menu, not when it loses focus by clicking somewhere else.
This probably falls under keyboard navigation or focus related issue. Don't know who owns that code. Giving to Browser team for further investigation.
Assignee: radha → trudelle
Component: History: Session → Browser-General
->menus
Assignee: trudelle → hyatt
Component: Browser-General → XP Toolkit/Widgets: Menus
QA Contact: claudius → shrir
To reproduce reliably in RC2: Generate some history Click on the button for the dropdown back menu AND HOLD FOR AT LEAST 1 SECOND Release, and the dropdown menu will persist. click on one of the items in the list. Expected result: browser should load selected page and menu should disappear. Actual result: browser loads selected page, menu persists and keeps keyboard focus, but browser window moves to top. You can't type in a text field in the page. Holding when you click on the drop-down button is critical. If you just click quickly, you get the expected (correct) behavior. This is most likely why people have had a hard time reproducing. As I mentioned above, this is Mozilla RC2. Mac OS 9.2.2.
Thanks Michael, that solves the mystery for me. I got this bug almost always, but couldn't find out how to reproduce it. Keeping the mouse button down for at least one second is it. I can confirm the same bug on Mac OS X 10.1.3 and Mozilla 1.0 RC2 (and all prior versions since I've been using Mozilla, so this is not a recent regression thing). Another way to reproduce the bug is to keep the mouse pressed on the dropdown back menu mini-button, then click somewhere in the content area of the browser window. The dropdown back menu does not disappear as it should. The only way to get rid of it is to click on the mini-button again and *release the mouse button over it*.
I'm getting something which I believe is the same problem but with some minor differences. Notably, the menu doesn't drop behind the browser window for me. But it definitely persists. Using Mac OS X 10.1.4.
All those who see the problem: Is this a dupe of bug 102330? And are you still seeing it in 1.0 or later? pi
Not exactly a dup. 102330 reported two problems, and this is one of them. Yes, it is still there in 1.0, mac OS 9.2.2. In fact, it has gotten worse due to regressions in handling of multiple monitors. If you launch Moz 1.0 with a single monitor, sleep, and wake up with two monitors, the sticky menu may appear OFF SCREEN, meaning there is NO WORKAROUND to save the session -- the session must be killed. To be absolutely sure that the problem won't return, you have to exit and restart Mozilla. (I do the monitor switching very often because I put my powerbook to sleep at home, then wake it up at work with a seecond monitor plugged in.)
WorksForMe using Mac/2002052305 to perform the test regimen in comment #12.
There are two bugs here. (1) When your computer is trying to do lots of stuff at once, Mozilla thinks that a click is a click-and-hold. That's bug 117589. (2) When you do a click-and-hold on the Back menubutton, one copy of the Back menu opens because you clicked on the menubutton, and another copy of the menu opens because you clicked-and-held on the Back button (which includes the menubutton). That's bug 102330. Then when you choose an item from the frontmost copy of the menu, the other copy stays behind. *** This bug has been marked as a duplicate of 102330 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
mass duplicate verifications . For filtering purposes, pls use keywd "massdupverification"
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.