With the menu bar set to auto-hide, dragging an item from the history menu to the desktop breaks the menu bar

RESOLVED WORKSFORME

Status

()

Core
Layout: View Rendering
RESOLVED WORKSFORME
8 years ago
a year ago

People

(Reporter: u88484, Unassigned)

Tracking

({regression})

Trunk
x86_64
Windows 7
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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)
(Reporter)

Updated

8 years ago
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
(Reporter)

Comment 1

8 years ago
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.
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.
(Reporter)

Comment 3

8 years ago
Created attachment 423447 [details]
Screenshot

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.
(Reporter)

Comment 4

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

8 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
I still can't reproduce this.
Blocks: 526394
No longer blocks: 477256
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
Last Resolved: a year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.