implementation of window.confirm on GeckoView
Categories
(GeckoView :: General, enhancement, P3)
Tracking
(firefox66 wontfix, firefox67 wontfix, firefox68 fix-optional)
Tracking | Status | |
---|---|---|
firefox66 | --- | wontfix |
firefox67 | --- | wontfix |
firefox68 | --- | fix-optional |
People
(Reporter: karlcow, Unassigned)
References
()
Details
(Whiteboard: [webcompat] [geckoview:fenix:p2])
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.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
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.
Reporter | ||
Comment 3•5 years ago
|
||
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•5 years ago
|
||
(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.
Updated•5 years ago
|
Comment 5•5 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 6•5 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Comment 7•5 years ago
|
||
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•5 years ago
|
||
It sounds like the fix for this has landed in GeckoView, and will hit Fenix/Reference Browser when they update their instances of GV.
(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.
Updated•2 years ago
|
Description
•