494373 - fullscreen - new tab - non fullscreen > address bar broken

Status: VERIFIED FIXED

(Firefox :: General, defect, P2)

Description

[ewerybody]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729)

Similar to these ones:
https://bugzilla.mozilla.org/show_bug.cgi?id=439774
https://bugzilla.mozilla.org/show_bug.cgi?id=450859
https://bugzilla.mozilla.org/show_bug.cgi?id=452367
I cannot enter a URL when creating new tab in fullscreen F11-mode.

But what seems unreported for 3.5 beta 4:
The Adressbar is not working when coming back from fullscreen!
It keeps displaying "Search Bookmarks and History" grayed out and italic, even if you enter the field. Everything you type is then displayed the same way. Enter doesn't do anything.

Reproducible: Always

Steps to Reproduce:
1. hit F11 for fullscreen
2. press Ctrl+T for new Tab
3. hit F11 again
Actual Results:  
adressbar is grayed out, text italic, typing works but enter doesn't start a search

Expected Results:  
(Actually the adressbar should already be focussed If I press F11 and Ctrl+T but..)
It should be usable and focused as like in non-fullscreen mode when I'm back from fullscreen.

Comment 1

[singu.b+bugzilla]

Work around:

a) click
1. hit F11 for fullscreen
2. press Ctrl+T for new Tab
3. Show the hidden controls
4. Give the Adressbar focus with a click
4.1. (type something and it stays grey)
5. Remove Focus by clicking the white space
6. Click Adressbar again, now it works

b) Use F6
1. hit F11 for fullscreen
2. press Ctrl+T for new Tab
3. Show the Adressbar with F6
4. Type F6 again to get focus
4.1. (type something and it stays grey)
5. Remove Focus by type F6
6. Type F6 again to regain focus, now it works

Curios: The Bug does not happen if the controls are visible and a new Tab is created


Expected Results: 0 clicks or 0 times type of F6 to enter a url in a new Tab

Comment 2

[Michael Haufe]

I can confirm that this bug also occurs on Windows XP:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090616 Firefox/3.5

Comment 3

[u88484]

This WFM.  Can you reproduce this in safe mode?

Comment 4

[Michael Haufe]

I was able to reproduce this on Windows Vista as well:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

1 - hit F11
2 - CTRL + T
3 - click in address bar

This only occurs on the initial focus, subsequent blur/focus acts as expected

Comment 5

[Sylvain Pasche]

I can reproduce with 3.5 on XP and win7. Didn't try with the latest trunk nightly as full screen is broken (bug 502133).

Comment 7

[Michael Ryan]

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ca9d3c35fe47&tochange=9dbded90af2a

Bisecting now...

Comment 8

[Michael Ryan]

Caused by 472302.

Comment 9

[Dão Gottwald [:dao]]

Can somebody reproduce this on trunk?

Comment 10

[Sylvain Pasche]

Trunk is working fine for me.

Comment 11

[Dão Gottwald [:dao]]

For me as well, resolving.

Comment 12

[Sylvain Pasche]

Don't you think it's worth backporting the fix to 3.5? That seems to be rather bad for users who like to browse in fullscreen.

The first step would be to identify what has fixed this on trunk and see if that's something trivial.

Comment 13

[Sylvain Pasche]

oh sorry, I didn't see the dependency on bug 494373. Yeah, that isn't a trivial fix for 3.5.

Comment 14

[Sylvain Pasche]

err, on bug 178324.

Comment 15

[Dão Gottwald [:dao]]

If we knew what exactly the issue is, a workaround could be implemented for 3.5.

Comment 16

[Dão Gottwald [:dao]]

I see what's going on...

Comment 17

[Dão Gottwald [:dao]]

Attachment: 1.9.1 patch

Comment 18

[Dão Gottwald [:dao]]

Attachment: trunk patch

Comment 19

[Dão Gottwald [:dao]]

Attachment: updated trunk patch

Comment 20

[Ian Stirling.]

3.5.1 - this is reproducable - it seems only when the bar is hidden - if hte bar is visible when the new tab is created, it works.

Comment 22

[wolf]

Bug exists in 3.5.2.

Comment 26

[nietaki]

a sidenote: this bug is very inconvenient when using a netbook.

Comment 28

[Marius]

Still exists on Mozilla/5.0 (Windows; U; Windows NT 5.1; lt; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

Comment 29

[u88484]

(In reply to comment #22)
> Bug exists in 3.5.2.

(In reply to comment #28)
> Still exists on Mozilla/5.0 (Windows; U; Windows NT 5.1; lt; rv:1.9.1.3)
> Gecko/20090824 Firefox/3.5.3

No further comments are needed.  The bug is assigned and will be fixed.

Comment 30

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

(In reply to comment #16)
> I see what's going on...

Can you explain in the bug? It may be obvious to you as you're writing the patch, but a sentence or two explaining the problem the patch solves really makes reviewing easier.

I can't seem to reproduce the issue... is the fix making sure to call mouseoverToggle(true) before trying to focus the url bar? Why is that necessary? Does focus() throw? I don't see mouseoverToggle doing anything that would affect a synchronous call to focus() (setting the collapse attribute wouldn't have an effect until a layout flush, AFAICT).

Comment 31

[Dão Gottwald [:dao]]

(In reply to comment #30)
> I can't seem to reproduce the issue...

It looks like the underlying bug has been fixed during the last few months. It's still present on 1.9.1. The patch is needed for bug 439774 either way.

> is the fix making sure to call
> mouseoverToggle(true) before trying to focus the url bar?

Yes.

> Why is that necessary?

Because focus() alone doesn't make the location bar visible, and puts the textbox in a weird state on 1.9.1 (not on trunk and 1.9.2 anymore).

> Does focus() throw?

Nope. On trunk and 1.9.2 it's now a no-op.

> I don't see mouseoverToggle doing anything that
> would affect a synchronous call to focus() (setting the collapse attribute
> wouldn't have an effect until a layout flush, AFAICT).

Well, it worked last time I tried the patch.

Comment 32

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/fe44a4b6eee0

Comment 33

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/7d7b6eaef27f

Comment 34

[Daniel Veditz [:dveditz]]

Comment on attachment 387296 [details] [diff] [review]
1.9.1 patch

Approved for 1.9.1.5, a=dveditz for release-drivers

Comment 35

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5cf93cb87229

Comment 36

[Mihnea Simian]

Running Mozilla/5.0 (Windows; U; Windows NT 5.1; ro; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 and this is still not fixed!

Comment 37

[Kevin Brosnan]

It will be fixed in 3.5.5

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could this have caused a substantial memory use increase?

http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/b5259d888d25ac8d#
http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/79c545d7bd6d64d8#
http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/76d42a9d4593ceab#
http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/4ff9b5c8f62dd44b#
http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/3983e9b6f35bff1f#
http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/dcc3901aee0be5a4#

Comment 39

[Dão Gottwald [:dao]]

I don't think so, at least not directly. If it somehow triggers a deeper bug, maybe... I could back this out temporarily to see if that makes a difference.

Comment 41

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed on trunk, 1.9.2, and 1.9.1 with builds on all platforms like:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091112 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20091112045818

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b3pre) Gecko/20091113 Namoroka/3.6b3pre (.NET CLR 3.5.30729) ID:20091113051922

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091102 Shiretoko/3.5.5pre (.NET CLR 3.5.30729) ID:20091102042030

Comment 42

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Until we have an automated test this is covered by Litmus:
https://litmus.mozilla.org/show_test.cgi?id=9704

Comment 45

[Giorgio Sironi]

Although (In reply to comment #41)
> Verified fixed on trunk, 1.9.2, and 1.9.1 with builds on all platforms like:
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091112
> Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20091112045818
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b3pre) Gecko/20091113
> Namoroka/3.6b3pre (.NET CLR 3.5.30729) ID:20091113051922
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091102
> Shiretoko/3.5.5pre (.NET CLR 3.5.30729) ID:20091102042030

Still present on 3.5.5 official.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5

Comment 46

[Lode Claassen]

On Windows as well (Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5)

Comment 47

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Firefox 3.5.5 was a firedrill release. All other fixes have been pushed to Firefox 3.5.6 which will be released soon.