Closed
Bug 542115
Opened 14 years ago
Closed 8 years ago
With the menu bar set to auto-hide, dragging an item from the history menu to the desktop breaks the menu bar
Categories
(Core :: Web Painting, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: u88484, Unassigned)
References
Details
(Keywords: regression)
Attachments
(1 file)
37.48 KB,
image/png
|
Details |
With the menu bar set to auto-hide, dragging an item from the history menu breaks the menu bar STR: 1) View->Toolbars, uncheck the menu bar so that it automatically hides when the chrome doesn't have focus 2) Resize the browser so you can see the desktop 3) Hit the alt key to show the menu bar 4) Open the history menu 5) Drag and drop a history item to the desktop (menu auto hides) 6) Hit the alt key to show the menu bar and all text has disappeared You can barely see a shadow from the file menu at the very, very top left of the window. Use a menu shortcut key for the menus to reappear (CTRL+T)
Summary: With the menu bar set to auto-hide, dragging an item from the history menu breaks the menu bar → With the menu bar set to auto-hide, dragging an item from the history menu to the desktop breaks the menu bar
This might be a regression from bug 498852. First time I've ever tried doing this action so I'm not sure if it is new or not. I'll checked for a regression range sometime later this week if someone doesn't find it before me.
Comment 2•14 years ago
|
||
I can't reproduce this bug, or I don't understand it.
> Use a menu shortcut key for the menus to reappear (CTRL+T)
I'm assuming you mean Alt+T, as Ctrl+T opens a new tab.
Arrow points to where the File menu shadow barely shows. You have to hit just the alt key first for the menu bar to appear. If you hit alt+T first then everything appears fine. You only have to hit alt+T to get things working correctly. Alt+F, E, V, H, B, or H will also work in lieu of alt+T.
This is a regression from 3.6. I still haven't tried yesterday's nightly yet to confirm if bug 498852 caused this.
Keywords: regression,
regressionwindow-wanted
Comment 5•14 years ago
|
||
Regression window: works: http://hg.mozilla.org/mozilla-central/rev/5dca6c28cca5 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100111 Minefield/3.7a1pre ID:20100111152135 broken: http://hg.mozilla.org/mozilla-central/rev/a43e2f7eda8f Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100112 Minefield/3.7a1pre ID:20100112034523 pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5dca6c28cca5&tochange=a43e2f7eda8f candidate regress bug: Bug 526394 - Move scrolling out of the view system into layout
Comment 6•14 years ago
|
||
I still can't reproduce this.
Component: Toolbars and Toolbar Customization → Layout: View Rendering
Keywords: regressionwindow-wanted
Product: Toolkit → Core
QA Contact: toolbars → layout.view-rendering
Considering the fact that I cannot reproduce this and the fact that the reporter's account is no longer active to request more info, I will mark this as Resolved-Worksforme. If anyone can still reproduce it, feel free to reopen the issue and provide more information.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•