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

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[l0r3n2o]

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.

Comment 1

[l0r3n2o]

Attachment: Screenshot of the problem

Resizing the window restores default behavior

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Bug 625888 reported that this also happens when opening a window from About Firefox

Comment 5

[Rich Parker]

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

[Alice0775 White]

Attachment: workaround

This workaround delays the timing of positioning of the titlebar.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Alice, you should get someone (dao, maybe?) to review that patch. If it passes review, it has implicit a=beltzner

Comment 10

[Edo Karabas]

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

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

** 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

Comment 15

[Dão Gottwald [:dao]]

Comment on attachment 511097 [details] [diff] [review]
workaround

This causes the UI to visibly lag behind e.g. when maximizing the window :(

Comment 16

[Lozzy]

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

[Rich Parker]

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.

Comment 18

[Dão Gottwald [:dao]]

Attachment: patch

When this bug happens, everything is pushed down momentarily. Refactored the implementation to be immune to this.

Comment 21

[Rich Parker]

Is this going to be fixed in 4.0?

Comment 22

[Asa Dotzler [:asa]]

(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

[Lozzy]

(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

Comment 25

[robinbanks]

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

Comment 26

[robinbanks]

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

Comment 27

[robinbanks]

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

Comment 30

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 31

[Dão Gottwald [:dao]]

Attachment: patch

Comment 32

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 521900 [details] [diff] [review]
patch

rs=me

Comment 33

[Dão Gottwald [:dao]]

http://hg.mozilla.org/projects/cedar/rev/52631a0b9a46

Comment 34

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/52631a0b9a46

Comment 35

[mdew]

This was a annoying bug on Firefox 4.0 release, possible to merge this into the next 4.0 stable also?

Comment 36

[Simona Badau, Desktop QA]

Verified on:
Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre

Comment 37

[Rich Parker]

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

Comment 38

[Dão Gottwald [:dao]]

Comment on attachment 521900 [details] [diff] [review]
patch

Isolated patch and baked on trunk, so yes, I think this can land on 2.0.

Comment 39

[Rich Parker]

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 40

[Daniel Veditz [:dveditz]]

Comment on attachment 521900 [details] [diff] [review]
patch

not planning any more mozilla2.0 releases, this isn't a chemspill bug.