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

VERIFIED FIXED in Firefox 5

Status

()

VERIFIED FIXED
8 years ago
5 years ago

People

(Reporter: l0r3n2o88, Assigned: dao)

Tracking

({polish, regression})

unspecified
Firefox 5
x86_64
Windows 7
polish, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -, status2.0 wontfix)

Details

(Whiteboard: [softblocker], URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

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

Comment 1

8 years ago
Created attachment 503494 [details]
Screenshot of the problem

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

Comment 5

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

Comment 6

8 years ago
Created attachment 511097 [details] [diff] [review]
workaround

This workaround delays the timing of positioning of the titlebar.

Updated

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

Updated

8 years ago
Duplicate of this bug: 635624

Updated

8 years ago
Attachment #511097 - Attachment is patch: true

Comment 10

8 years ago
I hope it will be fixed before final build, because it is visible regression.

Updated

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

Updated

8 years ago
Duplicate of this bug: 639145
(Assignee)

Updated

8 years ago
Duplicate of this bug: 639285
(Assignee)

Comment 15

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

Comment 16

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

Comment 17

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

Comment 18

8 years ago
Created attachment 518369 [details] [diff] [review]
patch

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)
(Assignee)

Updated

8 years ago
Component: Theme → General
QA Contact: theme → general
(Assignee)

Updated

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

Updated

8 years ago
Duplicate of this bug: 641831

Updated

8 years ago
Duplicate of this bug: 641831

Comment 21

8 years ago
Is this going to be fixed in 4.0?

Comment 22

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

Comment 23

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

Updated

8 years ago
Attachment #518369 - Flags: feedback?(felipc)
Attachment #518369 - Flags: feedback?(felipc) → feedback+
Duplicate of this bug: 643116

Comment 25

8 years ago
FYI.
Seeing the same behavior on  XP Pro SP3.(FF4rc2)

Comment 26

8 years ago
Should add, only seeing this going to ...Options/Advanced/Update/Show Update History/[b]Details[/b].

Comment 27

8 years ago
(In reply to comment #26)
> Should add, seeing this going to ...Options/Advanced/Update/Show Update
> History/[b]Details[/b].

Updated

8 years ago
Duplicate of this bug: 643402
(Assignee)

Updated

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

Comment 31

8 years ago
Created attachment 521900 [details] [diff] [review]
patch
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+
(Assignee)

Comment 33

8 years ago
http://hg.mozilla.org/projects/cedar/rev/52631a0b9a46
Whiteboard: [softblocker][pre-approved by beltzner] → [softblocker] fixed-in-cedar

Comment 34

8 years ago
http://hg.mozilla.org/mozilla-central/rev/52631a0b9a46
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [softblocker] fixed-in-cedar → [softblocker]
Target Milestone: --- → Firefox4.2

Comment 35

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

Comment 37

8 years ago
If this is only targeted for 4.2, I'll add my vote to fix it in the very next 4.0 patch.
(Assignee)

Comment 38

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

Updated

8 years ago
Target Milestone: Firefox5 → Firefox 5

Comment 39

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

Updated

7 years ago
Duplicate of this bug: 632747
You need to log in before you can comment on or make changes to this bug.