User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110113 Firefox/4.0b10pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110113 Firefox/4.0b10pre In last nightly when i click the "Learn more" link in geolocation dialog, toolbars and tab bar move upwards to align to Firefox menu button. This happens obviously only with hidden menu bar and tabs on top. Reproducible: Always Steps to Reproduce: 1.Enter a page that use geolocation (ex. http://www.mozilla.com/en-US/firefox/geolocation/) 2.When is required to share the location, click "Learn more" link in the dialog 3.A new windows opens Actual Results: Tabs on top bar, navigation toolbar and bookmarks toolbar move upwards. Expected Results: Behaviour should not change. Tried in Windows 7 x64 with Windows Aero turned on.
Created attachment 503494 [details] Screenshot of the problem Resizing the window restores default behavior
Status: UNCONFIRMED → NEW
blocking2.0: --- → final+
Ever confirmed: true
Summary: Firefox toolbars shift when opening link from geolocation dialog → Firefox dialogs open a new maximized window with tabs in titlebars 1 pixel too high
Bug 625888 reported that this also happens when opening a window from About Firefox
Keywords: polish, regression
To repeat what I said in duplicate bug 632838, this also happens for any link targeted to a new window (target="_blank") and other internal Firefox links (e.g. "See all" in Add-ons Manager), but NOT when manually Shift-clicking a link or right-clicking and choosing "Open Link in New Window". Clue? The difference is about 6 pixels.
Created attachment 511097 [details] [diff] [review] workaround This workaround delays the timing of positioning of the titlebar.
Alice, you should get someone (dao, maybe?) to review that patch. If it passes review, it has implicit a=beltzner
Whiteboard: [softblocker] → [softblocker][pre-approved by beltzner]
I hope it will be fixed before final build, because it is visible regression.
Summary: Firefox dialogs open a new maximized window with tabs in titlebars 1 pixel too high → Firefox dialogs and window=blank target links open a new maximized window with tabs in titlebars 1 pixel too high
** PRODUCT DRIVERS PLEASE NOTE ** This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons: - it was marked as a soft blocking issue without a requirement for beta coverage
blocking2.0: final+ → .x+
Comment on attachment 511097 [details] [diff] [review] workaround This causes the UI to visibly lag behind e.g. when maximizing the window :(
Attachment #511097 - Flags: review?(dao) → review-
I'm a little concerned that RC1 has been released, yet this bug is still prominent. I get the feeling that, because it's such an easy bug to discover, there will probably be a lot of people bringing it up in SUMO or creating duplicate bugs.
Agreed. I run into this many, many times a day. Although it has no functional impact as far as I know, it's bad enough that I often restore the window down and maximize it again as a work-around. The subject line also underplays the bug somewhat since the discrepancy is 5 or 6 pixels, not 1. No offense to anyone, but this doesn't seem to be getting much attention. If the turn-around time from bug to proposed fix to review is a month at a time, it's too late. Disclaimer: Although I develop enterprise business software for a very large company, I don't work on Firefox or know much about its planning, so I'll shut up now.
Created attachment 518369 [details] [diff] [review] patch When this bug happens, everything is pushed down momentarily. Refactored the implementation to be immune to this.
Component: Theme → General
QA Contact: theme → general
Summary: Firefox dialogs and window=blank target links open a new maximized window with tabs in titlebars 1 pixel too high → With tabs in the title bar, Firefox dialogs and target=_blank links open a new maximized window with tabs cut off at the top
Is this going to be fixed in 4.0?
(In reply to comment #21) > Is this going to be fixed in 4.0? No. No bugs that are not fixed yet are going to be fixed in Firefox 4.
(In reply to comment #21) > Is this going to be fixed in 4.0? Asa already answered, but to expand; It looks like it will go in 4.0.1, which I can assume will be accelerated to include a number of patches which didn't make the 4.0 deadline. This is the impression I got from this conversation; http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/18a347956e4693eb
Attachment #518369 - Flags: feedback?(felipc) → feedback+
FYI. Seeing the same behavior on XP Pro SP3.(FF4rc2)
Should add, only seeing this going to ...Options/Advanced/Update/Show Update History/[b]Details[/b].
(In reply to comment #26) > Should add, seeing this going to ...Options/Advanced/Update/Show Update > History/[b]Details[/b].
Comment on attachment 518369 [details] [diff] [review] patch >diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js >- let tabsToolbar = $("TabsToolbar"); >+ let tabsToolbar = rect($("TabsToolbar")); > this._draghandle = new tmp.WindowDraggingElement(tabsToolbar, window); This looks wrong - WindowDraggingElement expects an element that it can add an event listener to.
Attachment #518369 - Flags: review?(gavin.sharp) → review-
Created attachment 521900 [details] [diff] [review] patch
Comment on attachment 521900 [details] [diff] [review] patch rs=me
Attachment #521900 - Flags: review?(gavin.sharp) → review+
Whiteboard: [softblocker][pre-approved by beltzner] → [softblocker] fixed-in-cedar
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [softblocker] fixed-in-cedar → [softblocker]
Target Milestone: --- → Firefox4.2
This was a annoying bug on Firefox 4.0 release, possible to merge this into the next 4.0 stable also?
Verified on: Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre
Status: RESOLVED → VERIFIED
If this is only targeted for 4.2, I'll add my vote to fix it in the very next 4.0 patch.
Comment on attachment 521900 [details] [diff] [review] patch Isolated patch and baked on trunk, so yes, I think this can land on 2.0.
Attachment #521900 - Flags: approval2.0?
I apologize for going a little off topic, but I'm not familiar with the version terminology, and I couldn't find a version-based Firefox roadmap via Google. Is this in 4.0.1? If not, what's the timeline for 4.2? A link to this information would suffice. Thanks.
Comment on attachment 521900 [details] [diff] [review] patch not planning any more mozilla2.0 releases, this isn't a chemspill bug.
Attachment #521900 - Flags: approval2.0? → approval2.0-
You need to log in before you can comment on or make changes to this bug.