1421634 - If a tab that has the autofill fields is detached to a new window the autofill doesn't work

Status: NEW

(Toolkit :: Form Autofill, defect, P3)

Description

[ovidiu boca[:Ovidiu]]

Affected versions]:

Tested on Nightly 59.0a1(2017-11-29)

[Affected platforms]:

Tested on Mac OS X 10.13, Windows 10

[Steps to reproduce]:

Prerequisites:
 1. Make sure you have at least two saved profile.
 
 STR:

1. Go to https://luke-chang.github.io/autofill-demo/basic.html
2. Double click on the "Name" field and select a profile, fill in.
3. Click on a field from the demo page.
4. Drag the tab to a new window and click again on the same field, like in the previews step, from the demo page.


[Expected result]:

A drop down with 2 buttons is shown. On Windows, you have "Clear Form" and "Options" and on Mac and Linux you have "Clear Form" and "Preferences".

[Actual result]:

Nothing happens. 

NOTE: THis issue is also related to autofill, not only with the "Clear Form" button.

The worst part is when you put back the detached tab into the original window, all the fields are stuck, there is nothing actionable, you need to refresh the page.

Comment 1

[Sean Lee [:seanlee][:weilonge]]

(In reply to ovidiu boca[:Ovidiu] from comment #0)
> Affected versions]:
> 
> Tested on Nightly 59.0a1(2017-11-29)
> 
> [Actual result]:
> 
> Nothing happens. 
>

This issue can be reproduced only when the focus is still remained after the tag dragged out of the previous window. I am going to check why startSearch() is not triggered in the new window.
 
> NOTE: THis issue is also related to autofill, not only with the "Clear Form"
> button.
> 
> The worst part is when you put back the detached tab into the original
> window, all the fields are stuck, there is nothing actionable, you need to
> refresh the page.
This issue could be not related to FormAutofill without showing FormAutofill popup. This can be reproduced with the configuration of this: extensions.formautofill.available => "off"
bug 1422687 is created for discussing separately.

Comment 2

[Sean Lee [:seanlee][:weilonge]]

Attachment: The log of dragging a tab out of its window

(In reply to Sean Lee [:seanlee][:weilonge] from comment #1)
> (In reply to ovidiu boca[:Ovidiu] from comment #0)
> > [Actual result]:
> > Nothing happens. 
> 
> This issue can be reproduced only when the focus is still remained after the
> tag dragged out of the previous window. I am going to check why
> startSearch() is not triggered in the new window.
>  

This issue is caused by early returning of nsFormFillController::ShowPopup() due to null pointer of mInput.
`mInput` is always assigned by `StartControllingInput`, and it will be removed by `StopControllingInput`.

When the tab is being dragged out of its window, the race condition happens between `StartControllingInput` and `StopControllingInput`.

Eventually, `StopControllingInput` uses `SetInput` to clear `mInput` by assigning null pointer.

I am going to figure out what makes the timing issue.

BTW, this issue can not be reproduced in non-e10s mode (--disable-e10s), and `SetInput` did assign a non-null pointer to mInput.

[1] https://searchfox.org/mozilla-central/rev/ba2b0cf4d16711d37d4bf4d267b187c9a27f6638/toolkit/components/satchel/nsFormFillController.cpp#1281

Comment 3

[ovidiu boca[:Ovidiu]]

We just test this issue on Ubuntu 16.04 and it can't be reproduced if you drag and put back the tab everything works as expected.

Comment 4

[Sean Lee [:seanlee][:weilonge]]

Since `ePageHide`[1] event or calling nsFormFillController::DetachFromBrowser[2] are after `eFocus` event, `mInput` will be cleared by `StopControllingInput`. I guess this is a similar issue with the one that MattN mentioned in bug 1385901 comment1.


[1] https://searchfox.org/mozilla-central/rev/ba2b0cf4d16711d37d4bf4d267b187c9a27f6638/toolkit/components/satchel/nsFormFillController.cpp#978
[2] https://searchfox.org/mozilla-central/rev/ba2b0cf4d16711d37d4bf4d267b187c9a27f6638/toolkit/content/browser-content.js#1531

Comment 5

[Luke Chang [:lchang] (inactive)]

Remove this bug from V2 scope as it's a long-standing issue that affects not only Form Autofill but also Form History and Login Manager, and has no trivial solution to fix it.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:serg, could you have a look please?

For more information, please visit BugBot documentation.