sticky back history button




17 years ago
10 years ago


(Reporter: bingalls, Assigned: hyatt)


Mac System 8.5

Firefox Tracking Flags

(Not tracked)




17 years ago
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.

Comment 1

17 years ago
Bruce, please provide Steps to Reproduce this problem.

Comment 2

17 years ago
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.

Comment 3

17 years ago
Fwiw, WorksForMe using Mac/2001112011 (0.9.6). I'll try a newer nightly.

Comment 4

17 years ago
Still WorksForMe using Mac/2001121308.
session history
Assignee: pchen → radha
Component: XP Apps → History: Session
QA Contact: sairuh → claudius

Comment 6

17 years ago
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.

Comment 7

17 years ago
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.

Comment 8

17 years ago
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

Comment 9

17 years ago
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

Comment 11

17 years ago
Assignee: trudelle → hyatt
Component: Browser-General → XP Toolkit/Widgets: Menus
QA Contact: claudius → shrir

Comment 12

17 years ago
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.

Comment 13

17 years ago
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*.

Comment 14

17 years ago
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.

Comment 15

17 years ago
All those who see the problem: Is this a dupe of bug 102330?

And are you still seeing it in 1.0 or later?


Comment 16

17 years ago
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.)

Comment 17

17 years ago
WorksForMe using Mac/2002052305 to perform the test regimen in comment #12.

Comment 18

17 years ago
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 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 19

16 years ago
mass duplicate verifications . For filtering purposes, pls use keywd



10 years ago
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.