1501202 - implementation of window.confirm on GeckoView

Status: NEW

(GeckoView :: General, enhancement, P3)

Description

[Karl Dubost💡 :karlcow]

This is a spinoff of the webcompat issue https://webcompat.com/issues/19418


Steps to reproduce

1 Navigate to site
2 popup asks to redirect to mobile site
3 hit cancel
4 redirect to mobile anyway
5 hit "LINKcat (full site)" link
6 GOTO 20


This is happening only in GeckoView

The popup in that page is a window.confirm message. 


```js
{
    var response = confirm('Do you want to go to the mobile-optimized version of this site?');
    if (response) {
        dispatch();
    } else {
        set_no_redirect();
    }
}
};```


Because it's not possible right now to remote debug GeckoView, I'm opening this issue here. 

Is window.confirm properly implemented in GeckoView. if yes that would remove one step in our analysis on the webcompat issue. If not, we found the culprit, aka if it always return a truthy value for JS.

Comment 1

[Chris Peterson [:cpeterson]]

Resetting bug priority so GeckoView triage will review.

Comment 2

[Chris Peterson [:cpeterson]]

Karl, how important is this problem for webcompat?

We will need to use a GV PromptDelegate to ask the app to show the confirmation UI.

Comment 3

[Karl Dubost💡 :karlcow]

This is the only issue of this kind on Firefox Focus + Gecko View.
I can't reproduce on Fennec (Firefox Android)
I haven't tried yet on Fenix

(a couple of minutes later… tune intermission install fenix background music)

This is happening on Fenix. So this is indeed a difference with Chrome and a "regression" with regards to Fennec.
Now this is the only site have seen it used so far.

Comment 4

[Chris Peterson [:cpeterson]]

(In reply to Karl Dubost💡 :karlcow from comment #3)

I can't reproduce on Fennec (Firefox Android)
...
This is happening on Fenix. So this is indeed a difference with Chrome and a "regression" with regards to Fennec.

Thanks for checking. Since this is a GeckoView regression, I'll tag this bug to be fixed in Fenix after the MVP release.

Comment 5

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 6

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 7

[Thomas Wisniewski [:twisniewski]]

This (or something similar) is affecting GitHub's "mark as read" feature as well. If I open the remote devtools on any page, and run confirm("whatever"), then tap "OK", it will return false. But if I repeat the exact same command, it starts returning true when I tap "OK". But if I change the string in the confirm call (say, confirm("whatever2")) then it returns false again the first time. Likewise, refreshing the page will have it return false for the first command.

This was discovered in https://webcompat.com/issues/31522, but it seems to affect any page, not just GitHub.

Comment 8

[Thomas Wisniewski [:twisniewski]]

It sounds like the fix for this has landed in GeckoView, and will hit Fenix/Reference Browser when they update their instances of GV.

Comment 9

[Mateusz Mikuła [:mati865]]

(In reply to Thomas Wisniewski [:twisniewski] from comment #8)

It sounds like the fix for this has landed in GeckoView, and will hit Fenix/Reference Browser when they update their instances of GV.

The issue with Github confirmation prompts has been fixed in recent Firefox Preview.

Comment 10

[Chris Peterson [:cpeterson]]

Tasks and enhancements should have severity N/A.