Closed Bug 1434275 Opened 6 years ago Closed 6 years ago

URLBar doesn't get focus on new tab on OSX in fullscreen

Categories

(WebExtensions :: Frontend, defect)

x86_64
macOS
defect
Not set
normal

Tracking

(firefox-esr52 unaffected, firefox-esr60 wontfix, firefox59 wontfix, firefox60 wontfix, firefox61+ verified)

VERIFIED FIXED
mozilla61
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 + verified

People

(Reporter: mostlygeek, Assigned: kmag)

References

Details

(Keywords: regression)

Attachments

(1 file)

I'm using the Webextension Tabliss[1] and on OSX. 

Problem: 

Creating a newtab in fullscreen mode does not put the focus on the URLBar. When not in fullscreen it works as expected. Tested this in beta (59) and nightly (60.0a) and both have this bug. 

Expected behavior: 

The URLBar should get focus in fullscreen mode. 


[1] https://github.com/joelshepherd/tabliss/issues/25
I'm on 60.0a1 (2018-01-30) and I'm unable to reproduce this. It worked for Tabby Cat when I first tried, installed Tabliss and it still worked, restarted Firefox and it still worked again.

Is it happening every time or just on the first new tab?
Flags: needinfo?(bwong)
See Also: → 1434312
I just tested this on my secondary monitor and I don't see it getting selected the first time I open a new tab. This is because there is supposed to be a doorhanger to confirm that you would like to use this New Tab page, for some reason it doesn't appear on the secondary monitor.

These could be related but it should only be happening once. I filed bug 1434312 for the first New Tab issue.
I have a 13" MBP on Sierra with an external monitor: 

Bug happens: 

- full screen on both monitors
- full screen + split screen (beta on left, nightly on right) 

Other behavior: 

- the doorhanger shows up for me (nightly) in fullscreen confirming newtab change
- if the focus is on the URLBar then (cmd+t) to create a new tab, focus is maintained on URLBar
- if focus is *NOT* on URLBar, then (cmd+t) newtab, the focus is *NOT* on the URLBar (but it should be)
Flags: needinfo?(bwong)
(In reply to Mark Striemer [:mstriemer] from comment #1)

> Is it happening every time or just on the first new tab?

It happens every time if the focus is *not* on the URLBar. 
When the doorhanger is shown, it puts focus on the URLBar so then the bug doesn't happen.
NI mstriemer to follow up.
Flags: needinfo?(mstriemer)
My friend was able to reproduce this and I just stepped through the code on his machine. The new tab isn't being treated as empty since it is "busy". I am able to reproduce this on release now and flipping the extensions.webextensions.remote pref fixes it.

The line that causes this is in the `isTabEmpty()` function [1]. It seems that the tab is busy without out-of-process extensions which is causing the tab to not be considered empty.

@dao would it be okay to make the busy check conditional on this not being the new tab page?

[1] https://searchfox.org/mozilla-central/rev/99df6dad057b94c2ac4d8b12f7b0b3a7fdf25d04/browser/base/content/browser.js#7170
Flags: needinfo?(mstriemer) → needinfo?(dao+bmo)
This seems to be fixed in Nightly. 
Not fixed in Beta 60.
(In reply to Benson Wong [:mostlygeek] from comment #7)
> This seems to be fixed in Nightly. 
> Not fixed in Beta 60.

Can you use mozregression to find the range in which this got fixed? We might be able to uplift that to 60.
Flags: needinfo?(dao+bmo) → needinfo?(bwong)
attached the output from mozregression. It seems to have narrowed it down to: 

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3eef48c0a0d9530f463d4f38dfc271925ca4d5d6&tochange=79044302abd1165ed375708201090281972d32d8

Let me know if this helps or if I should run mozregression differently.
Flags: needinfo?(bwong)
This is fixed by out of process extensions so it should be [1] that fixes it. That is currently slated to be enabled in 61 and is being tested by QA now. I don't think we'd uplift enabling OOP earlier than 61.

Tracking 61 so we can resolve this when OOP is definitely in our out for 61.

[1] https://hg.mozilla.org/integration/mozilla-inbound/rev/3514a63add08
No longer blocks: 1385403
Depends on: 1385403
OOP extensions were officially preffed on for OSX to ride the 61 train. We should get QE to verify this on Beta 61 builds, though.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: qe-verify+
Resolution: --- → FIXED
I have reproduced this issue using Firefox 60.0a1 (2018.01.30) on Mac OS X 10.13.5.
I can confirm this issue is fixed, I verified using Firefox 61.0b4 Mac OS X 10.13.5.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Assignee: nobody → kmaglione+bmo
Target Milestone: --- → mozilla61
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: