Closed
Bug 115223
Opened 23 years ago
Closed 22 years ago
sticky back history button
Categories
(Core :: XUL, defect)
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.
Reporter | ||
Comment 2•23 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.
Fwiw, WorksForMe using Mac/2001112011 (0.9.6). I'll try a newer nightly.
Comment 5•23 years ago
|
||
session history
Assignee: pchen → radha
Component: XP Apps → History: Session
QA Contact: sairuh → claudius
Reporter | ||
Comment 6•23 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•23 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•23 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
selected.
Comment 9•23 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.
Comment 10•23 years ago
|
||
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•23 years ago
|
||
->menus
Assignee: trudelle → hyatt
Component: Browser-General → XP Toolkit/Widgets: Menus
QA Contact: claudius → shrir
Comment 12•23 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•23 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•23 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•22 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?
pi
Comment 16•22 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•22 years ago
|
||
WorksForMe using Mac/2002052305 to perform the test regimen in comment #12.
Comment 18•22 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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Comment 19•22 years ago
|
||
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.
Description
•