Closed Bug 625367 Opened 9 years ago Closed 9 years ago

With tabs in the title bar, Firefox dialogs and target=_blank links open a new maximized window with tabs cut off at the top

Categories

(Firefox :: General, defect)

x86_64
Windows 7
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 5
Tracking Status
blocking2.0 --- -
status2.0 --- wontfix

People

(Reporter: l0r3n2o88, Assigned: dao)

References

()

Details

(Keywords: polish, regression, Whiteboard: [softblocker])

Attachments

(2 files, 2 obsolete files)

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.
Resizing the window restores default behavior
Blocks: 572160
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
Whiteboard: [softblocker]
Duplicate of this bug: 625888
Bug 625888 reported that this also happens when opening a window from About Firefox
Keywords: polish, regression
Duplicate of this bug: 632767
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.
Attached patch workaround (obsolete) — Splinter Review
This workaround delays the timing of positioning of the titlebar.
Duplicate of this bug: 633407
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]
Duplicate of this bug: 635624
Attachment #511097 - Attachment is patch: true
I hope it will be fixed before final build, because it is visible regression.
Attachment #511097 - Flags: review?(dao)
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
Duplicate of this bug: 636951
** 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+
Duplicate of this bug: 639145
Duplicate of this bug: 639285
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.
Attached patch patch (obsolete) — Splinter Review
When this bug happens, everything is pushed down momentarily. Refactored the implementation to be immune to this.
Assignee: nobody → dao
Attachment #511097 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #518369 - Flags: review?(gavin.sharp)
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
Duplicate of this bug: 641831
Duplicate of this bug: 641831
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)
Attachment #518369 - Flags: feedback?(felipc) → feedback+
Duplicate of this bug: 643116
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].
Duplicate of this bug: 643402
Duplicate of this bug: 645021
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-
Attached patch patchSplinter Review
Attachment #518369 - Attachment is obsolete: true
Attachment #521900 - Flags: review?(gavin.sharp)
Comment on attachment 521900 [details] [diff] [review]
patch

rs=me
Attachment #521900 - Flags: review?(gavin.sharp) → review+
http://hg.mozilla.org/projects/cedar/rev/52631a0b9a46
Whiteboard: [softblocker][pre-approved by beltzner] → [softblocker] fixed-in-cedar
http://hg.mozilla.org/mozilla-central/rev/52631a0b9a46
Status: ASSIGNED → RESOLVED
Closed: 9 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?
Target Milestone: Firefox5 → Firefox 5
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.
blocking2.0: .x+ → -
status2.0: --- → wontfix
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-
Duplicate of this bug: 632747
You need to log in before you can comment on or make changes to this bug.