Closed Bug 494373 Opened 12 years ago Closed 12 years ago

fullscreen - new tab - non fullscreen > address bar broken

Categories

(Firefox :: General, defect, P2)

3.5 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 3.7a1
Tracking Status
status1.9.2 --- beta1-fixed
blocking1.9.1 --- -
status1.9.1 --- .6-fixed

People

(Reporter: ewerybody, Assigned: dao)

References

Details

(Keywords: regression, verified1.9.1, verified1.9.2, Whiteboard: [fixes bug 439774])

Attachments

(2 files, 1 obsolete file)

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.
Version: unspecified → 3.5 Branch
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
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
This WFM.  Can you reproduce this in safe mode?
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
Whiteboard: qawanted
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: qawanted
Duplicate of this bug: 502405
Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ca9d3c35fe47&tochange=9dbded90af2a

Bisecting now...
Keywords: regression
Summary: fullscreen - new tab - non fullscreen > adressbar broken → fullscreen - new tab - non fullscreen > address bar broken
Caused by 472302.
Blocks: 472302
Can somebody reproduce this on trunk?
Trunk is working fine for me.
For me as well, resolving.
Status: NEW → RESOLVED
Closed: 12 years ago
Depends on: 178324
Resolution: --- → WORKSFORME
Target Milestone: --- → Firefox 3.6a1
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.
oh sorry, I didn't see the dependency on bug 494373. Yeah, that isn't a trivial fix for 3.5.
err, on bug 178324.
If we knew what exactly the issue is, a workaround could be implemented for 3.5.
I see what's going on...
Assignee: nobody → dao
Status: RESOLVED → REOPENED
Component: Tabbed Browser → General
OS: Windows 7 → All
QA Contact: tabbed.browser → general
Hardware: x86 → All
Resolution: WORKSFORME → ---
Attached patch 1.9.1 patchSplinter Review
Attachment #387296 - Flags: review?(gavin.sharp)
Attached patch trunk patch (obsolete) — Splinter Review
Attachment #387297 - Flags: review?(gavin.sharp)
Status: REOPENED → ASSIGNED
Blocks: 439774
Flags: blocking1.9.1.1?
Whiteboard: [fixes bug 439774]
Attachment #387297 - Attachment is obsolete: true
Attachment #388039 - Flags: review?(gavin.sharp)
Attachment #387297 - Flags: review?(gavin.sharp)
blocking1.9.1: --- → ?
Flags: wanted1.9.1.x+
Flags: blocking1.9.1.1?
Flags: blocking1.9.1.1-
blocking1.9.1: ? → -
Flags: wanted1.9.1.x+
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.
Duplicate of this bug: 507840
Bug exists in 3.5.2.
Duplicate of this bug: 509270
Duplicate of this bug: 513184
Duplicate of this bug: 514840
Flags: blocking-firefox3.6+
a sidenote: this bug is very inconvenient when using a netbook.
Duplicate of this bug: 516003
Still exists on Mozilla/5.0 (Windows; U; Windows NT 5.1; lt; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
(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.
Priority: -- → P2
(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).
(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.
Attachment #387296 - Flags: review?(gavin.sharp) → review+
Attachment #388039 - Flags: review?(gavin.sharp) → review+
http://hg.mozilla.org/mozilla-central/rev/fe44a4b6eee0
Status: ASSIGNED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Target Milestone: Firefox 3.6a1 → Firefox 3.7a1
Attachment #387296 - Flags: approval1.9.1.4?
Attachment #387296 - Flags: approval1.9.1.4? → approval1.9.1.5?
Comment on attachment 387296 [details] [diff] [review]
1.9.1 patch

Approved for 1.9.1.5, a=dveditz for release-drivers
Attachment #387296 - Flags: approval1.9.1.5? → approval1.9.1.5+
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!
It will be fixed in 3.5.5
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.
Duplicate of this bug: 527266
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
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Until we have an automated test this is covered by Litmus:
https://litmus.mozilla.org/show_test.cgi?id=9704
Flags: in-litmus+
Duplicate of this bug: 530315
Duplicate of this bug: 533321
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
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)
Firefox 3.5.5 was a firedrill release. All other fixes have been pushed to Firefox 3.5.6 which will be released soon.
Duplicate of this bug: 534585
Duplicate of this bug: 502185
You need to log in before you can comment on or make changes to this bug.