Closed Bug 1488213 Opened 6 years ago Closed 6 years ago

Firefox 63 does not take focus on start

Categories

(Remote Protocol :: Marionette, defect, P3)

Product:
Remote Protocol
Component:
Marionette
Version:
63 Branch
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: barancev, Unassigned)

Details

(Keywords: regression) 

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

Steps to reproduce:

Scenario in Selenium Java 3.14, geckodriver 0.21, firefox nightly 63:

WebDriver driver = new FirefoxDriver(options);
driver.get("https://output.jsbin.com/xuriqiz");
driver.findElement(By.id("plainButton")).click();
new WebDriverWait(driver, 10).until(
    driver -> driver.findElement(By.id("result")).getText().contains("focus"));


Actual results:

Test failed because the browser does not fire 'focus' event. But if I click browser window manually it passes the test.

See screencast: https://www.screencast.com/t/2v0XWYpLMQ


Expected results:

It is expected that no extra manual action is required. Firefox 61 and 62 work well.
Please note that when I load this HTML testcase and manually click the button I don't get `focus` events either. Those are only raised when I navigate with `Tab` to the button.

Also I don't see anything in the WebDriver spec, which instructs the remote end to focus the element, before synthesizing a click. 

I replicated it as Marionette test and I cannot reproduce it:

```
    def test_submit_alert(self):
        self.marionette.navigate("https://output.jsbin.com/xuriqiz")
        self.marionette.find_element(By.ID, "plainButton").click()

        result = self.marionette.find_element(By.ID, "result")
        self.assertIn("focus", result.text)
```

Same when I run this with the Selenium Python bindings. Alexei, are you sure this above test is valid?
Flags: needinfo?(barancev)
I just want to say it's a regression issue. It used to work in Firefox 61 and 62 but not in 63. Also it works in IE and Chrome. So the test is "valid" in this meaning -- Firefox 63 behavior is different from older Firefox versions and other browsers.
Flags: needinfo?(barancev)
Priority: -- → P3
So what happens when you open `https://output.jsbin.com/xuriqiz` in a regular Firefox profile and manually click the button? Even when I use older releases of Firefox I never see a focus event to be raised.
Flags: needinfo?(barancev)
"mousedown focus mouseup click"
Tried today's Nightly (https://www.screencast.com/t/8qEEjkN0aa), beta 63.0b3 (64-bit) and ESR 52
Flags: needinfo?(barancev)
Ah, note that when focus events fire differ based on OS.
Ok, so opening `https://output.jsbin.com/xuriqiz` and clicking the button, seem to only raise the `focus` event on Windows and Linux, but clearly not on MacOS. I'm not sure if this is just a system setting (beside the one to enable all controls to reach focus), or somewhat expected on this platform.

Olli, do you know why there is such a difference?
Flags: needinfo?(bugs)
(In reply to Alexei Barantsev from comment #2)
> I just want to say it's a regression issue. It used to work in Firefox 61
> and 62 but not in 63. Also it works in IE and Chrome. So the test is "valid"
> in this meaning -- Firefox 63 behavior is different from older Firefox
> versions and other browsers.

Alexei, could you please test those two builds and check if the regression happened in that range?

https://archive.mozilla.org/pub/firefox/nightly/2018/09/2018-09-06-10-02-52-mozilla-central/
https://archive.mozilla.org/pub/firefox/nightly/2018/09/2018-09-06-23-21-39-mozilla-central/
Flags: needinfo?(barancev)
Yes, MacOS has different defaults for focusing.
If this is a regression, we really need a regression range.
Flags: needinfo?(bugs)
The regression here is most likely for Marionette. One bug which might have caused a change is bug 1398111.

Andreas, I don't find anything about raising `focus` events for `Element Click`. Was there a reason to not include that in the spec, maybe due to the platform differences?
Flags: needinfo?(ato)
2018-09-06-10-02-52 is broken
2018-09-06-23-21-39 is OK
(In reply to Henrik Skupin (:whimboo) from comment #9)

> I don't find anything about raising `focus` events for `Element
> Click`. Was there a reason to not include that in the spec, maybe
> due to the platform differences?

Since Element Click uses action primitives, and these delegate to
the Pointer Events specification, it is assumed that any focus
events resulting from clicking is defined there.
Flags: needinfo?(ato)
(In reply to Alexei Barantsev from comment #10)
> 2018-09-06-10-02-52 is broken
> 2018-09-06-23-21-39 is OK

Ok in which sense? Note that in that range a patch actually made the expected result to appear. But above you said that older builds were working. I'm a bit confused now.

(In reply to Andreas Tolfsen ❲:ato❳ from comment #11)
> Since Element Click uses action primitives, and these delegate to
> the Pointer Events specification, it is assumed that any focus
> events resulting from clicking is defined there.

Not yet, see bug 1490268.
pass -- Release 62.0 (20180830143136) -- "mousedown focus mouseup click"
fail -- 20180906100252 -- "mousedown mouseup click"
fail -- Developer 63.0b4 (20180906162647) -- "mousedown mouseup click"
pass -- 20180906232139 -- "mousedown focus mouseup click"
pass -- Nightly 64.0a1 (20180910220142) -- "mousedown focus mouseup click"

You must have reverted something that broke it :)
Flags: needinfo?(barancev)
So to clear this bug up. Given your last comment you cannot see it anymore in all the latest builds of Nightly and Beta, andnot the 62 release?
Flags: needinfo?(barancev)
Yes, the issue was actual in version 63, but it does not manifestate itself in the current Nightly that is version 64.
Flags: needinfo?(barancev)
But you still see it in the latest 63 beta or developer build?
Version 	63.0b4
Build ID 	20180906162647

This version is still affected.
Alexei do to a not working Windows VM I cannot really check this behavior right now. Would you mind to check the first developer and/or beta build of the Firefox 63 cycle if that was already a problem at the time of their release?

http://archive.mozilla.org/pub/devedition/releases/63.0b1/
http://archive.mozilla.org/pub/firefox/releases/63.0b3/
Flags: needinfo?(barancev)
Both ones are affected.

(The previous devedition 62.0b9 is not affected)
Flags: needinfo?(barancev)
Sorry, I meant to say devedition 62.0b20 is not affected
Ok, so I fixed my Window VM, and finally was able to run the test as given in comment 0. For me it passes with the Firefox 63.0 Beta 4 release:

> 1537352525360	webdriver::server	DEBUG	-> POST /session/4013c2cd-87f0-43d3-80ed-9a168a7b86d4/element {"using": "css selector", "value": "[id=\"plainButton\"]"}
> 1537352525362	Marionette	TRACE	0 -> [0,3,"WebDriver:FindElement",{"using":"css selector","value":"[id=\"plainButton\"]"}]
> 1537352525370	Marionette	TRACE	0 <- [1,3,null,{"value":{"element-6066-11e4-a52e-4f735466cecf":"53b9e015-aa3f-49f3-8995-ba38e4066a42"}}]
> 1537352525371	webdriver::server	DEBUG	<- 200 OK {"value":{"element-6066-11e4-a52e-4f735466cecf":"53b9e015-aa3f-49f3-8995-ba38e4066a42"}}
> 1537352525373	webdriver::server	DEBUG	-> POST /session/4013c2cd-87f0-43d3-80ed-9a168a7b86d4/element/53b9e015-aa3f-49f3-8995-ba38e4066a42/click {"id": "53b9e015-aa3f-49f3-8995-ba38e4066a42"}
> 1537352525375	Marionette	TRACE	0 -> [0,4,"WebDriver:ElementClick",{"id":"53b9e015-aa3f-49f3-8995-ba38e4066a42"}]
> JavaScript error: https://output.jsbin.com/xuriqiz, line 1: ReferenceError: register is not defined
> 1537352525626	Marionette	DEBUG	[6442450945] Canceled page load listener because no navigation has been detected
> 1537352525627	Marionette	TRACE	0 <- [1,4,null,{"value":null}]
> 1537352525627	webdriver::server	DEBUG	<- 200 OK {"value":null}
> 1537352525630	webdriver::server	DEBUG	-> POST /session/4013c2cd-87f0-43d3-80ed-9a168a7b86d4/element {"using": "css selector", "value": "[id=\"result\"]"}
> 1537352525631	Marionette	TRACE	0 -> [0,5,"WebDriver:FindElement",{"using":"css selector","value":"[id=\"result\"]"}]
> 1537352525637	Marionette	TRACE	0 <- [1,5,null,{"value":{"element-6066-11e4-a52e-4f735466cecf":"2bc9c7e2-1432-4af2-90d4-dfd3d1d5bbe1"}}]
> 1537352525638	webdriver::server	DEBUG	<- 200 OK {"value":{"element-6066-11e4-a52e-4f735466cecf":"2bc9c7e2-1432-4af2-90d4-dfd3d1d5bbe1"}}
> 1537352525640	webdriver::server	DEBUG	-> GET /session/4013c2cd-87f0-43d3-80ed-9a168a7b86d4/element/2bc9c7e2-1432-4af2-90d4-dfd3d1d5bbe1/text 
> 1537352525643	Marionette	TRACE	0 -> [0,6,"WebDriver:GetElementText",{"id":"2bc9c7e2-1432-4af2-90d4-dfd3d1d5bbe1"}]
> 1537352525675	Marionette	TRACE	0 <- [1,6,null,{"value":" mousedown focus mouseup click"}]
> 1537352525676	webdriver::server	DEBUG	<- 200 OK {"value":" mousedown focus mouseup click"}

So I'm not sure what I miss here, or which steps you exactly used to see this misbehavior.
Flags: needinfo?(barancev)
I have no idea what's wrong with my environment, but the issue is 100% reproducible in it.

On the other hand, I'm perfectly OK with the fact that the issue does not occur in version 64 and I'll not resist closing it.
Flags: needinfo?(barancev)
Ok, thanks. So lets close the bug given that I cannot do more here.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.