Open Bug 1899560 Opened 1 year ago Updated 1 year ago

2FA codes can’t be printed on Firefox Android in Custom Tab

Categories

(Firefox for Android :: Accounts and Sync, defect)

All
Android
defect

Tracking

()

People

(Reporter: jonalmeida, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Originally filed in FXA-9718.

FxA version:

  • 1.285.3

Prerequisites:

  • Have an Fx account;
  • Be signed in to Sync ;

Steps to reproduce:

  1. Tap on the 3 dots;
  2. Select the account and tap on “Manage account”;
  3. Tap of “Add” to activate 2FA;
  4. Proceed either by scanning QR code or manually adding the secret key into the Authenticator app;
  5. Enter 2FA the code after adding the authenticator app;
  6. Tap on “Print” on the back up codes screen;
  7. Observe behavior;

Expected result:

  • Print menu is opened allowing the user to print the backup codes;

Actual result:

  • Tapping on print does not open the print menu;

Notes:

  • A tooltip displaying the message “Printed” is displayed on Android;
  • Issue does not reproduce if fxa/settings is accessed directly through the URL;
  • Issue does not reproduce on Chrome;
  • See the attached media;

I wonder if Olivia would know how to better triage this. I wouldn't have expected this to not work in a Custom Tab, but worked fine in a regular tab when the print functionality was all in GV, if I recall correctly.

Ohh, interesting, I'll take a look and triage soon!

Initial thought is it isn't getting a browsing context for some reason. I'll look in the logs.

Flags: needinfo?(ohall)

The Bugbug bot thinks this bug should belong to the 'Fenix::Accounts and Sync' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: General → Accounts and Sync

Should we "just" prioritize bug 1856770 instead?

(In reply to Mark Hammond [:markh] [:mhammond] from comment #4)

Should we "just" prioritize bug 1856770 instead?

Yes, I agree! I'm going to add it as a blocker and increase severity on the bug.

Blocks: 1856770

I sometimes get slightly different behavior, I sometimes see an about:blank open and sometimes do not. Could you link the specific JS this print button is connected to?

Selected logs after print button pressed:

06-10 13:28:48.127 16892 16922 D GeckoViewNavigation: createContentWindowInFrame: uri=null where=3 flags=0 name=null
06-10 13:28:48.129 16892 16892 D GeckoSession: handleMessage GeckoView:OnLoadRequest uri=
06-10 13:28:48.134 16892 16922 D GeckoViewNavigation: handleNewSession: uri=null where=3 flags=0
06-10 13:28:48.134 16892 16892 D GeckoSession: handleMessage GeckoView:OnNewSession uri=
06-10 13:28:48.138 16892 16922 D GeckoViewModule: dispatch GeckoView:LoadUri, data={"uri":"","flags":0,"headerFilter":1}
06-10 13:28:48.138 16892 16922 D GeckoViewNavigation: onEvent: event=GeckoView:LoadUri, data={"uri":"","flags":0,"headerFilter":1}
06-10 13:28:48.140 16892 16922 D GeckoViewProgress: ProgressTracker onStateChange: isTopLevel=true, flags=0xf0001, status=NS_OK
06-10 13:28:48.140 16892 16922 D GeckoViewProgress: StateTracker onStateChange: isTopLevel=true, flags=0xf0001, status=NS_OK loadType=1
06-10 13:28:48.143 16892 16922 D GeckoViewNavigation: sessionContextId=null
06-10 13:28:48.147 16892 16892 D GeckoSession: handleMessage GeckoView:PageStart uri=about:blank
06-10 13:28:48.147 16892 16892 I GeckoSession: handleMessage GeckoView:PageStart uri=
06-10 13:28:48.155 16892 16922 D GeckoViewModule: registerListener ["GeckoViewContent:ExitFullScreen","GeckoView:ClearMatches","GeckoView:DisplayMatches","GeckoView:FindInPage","GeckoView:HasCookieBannerRuleForBrowsingContextTree","GeckoView:RestoreState","GeckoView:ContainsFormData","GeckoView:RequestCreateAnalysis","GeckoView:RequestAnalysisStatus","GeckoView:RequestAnalysisCreationStatus","GeckoView:PollForAnalysisCompleted","GeckoView:SendClickAttributionEvent","GeckoView:SendImpressionAttributionEvent","GeckoView:SendPlacementAttributionEvent","GeckoView:RequestAnalysis","GeckoView:RequestRecommendations","GeckoView:ReportBackInStock","GeckoView:ScrollBy","GeckoView:ScrollTo","GeckoView:SetActive","GeckoView:SetFocused","GeckoView:SetPriorityHint","GeckoView:UpdateInitData","GeckoView:ZoomToInput","GeckoView:IsPdfJs"]
06-10 13:28:48.155 16892 16922 D GeckoViewNavigation: onInit
06-10 13:28:48.155 16892 16922 D GeckoViewModule: registerListener ["GeckoView:GoBack","GeckoView:GoForward","GeckoView:GotoHistoryIndex","GeckoView:LoadUri","GeckoView:Reload","GeckoView:Stop","GeckoView:PurgeHistory","GeckoView:DotPrintFinish"]
06-10 13:28:48.155 16892 16922 D GeckoViewSettings: onSettingsUpdate: {"isExtensionPopup":false,"chromeUri":null,"screenId":0,"userAgentOverride":null,"allowJavascript":true,"userAgentMode":0,"viewportMode":0,"useTrackingProtection":false,"suspendMediaWhenInactive":false,"usePrivateMode":false,"unsafeSessionContextId":null,"displayMode":0,"sessionContextId":null,"fullAccessibilityTree":false}

// ... More inits etc. ...

06-10 13:28:48.160 16892 16922 D GeckoViewNavigation: onLocationChange
06-10 13:28:48.160 16892 16922 D GeckoViewProgress: SecurityTracker onLocationChange: location=about:blank, flags=0
06-10 13:28:48.160 16892 16922 W GeckoEventDispatcher: No listener for GeckoView:PageAction:Update
06-10 13:28:48.161 16943 17099 W Web Content: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." {file: "https://accounts.firefox.com/settings/static/js/main.225b2040.js" line: 2}]
06-10 13:28:48.161 16892 16922 D GeckoViewNavigation: onLocationChange
06-10 13:28:48.161 16892 16922 D GeckoViewTranslations: handleEvent: TranslationsParent:LanguageState
06-10 13:28:48.162   309   374 W EmuHWC2 : validate: layer 235 CompositionType 4, fallback
06-10 13:28:48.163 16892 16922 W GeckoEventDispatcher: No listener for GeckoView:PageAction:Update
06-10 13:28:48.163   309   374 W EmuHWC2 : No layers, exit, buffer 0xb4000071144b78e0
06-10 13:28:48.163 16892 16892 D GeckoSession: handleMessage GeckoView:PageStart uri=about:blank
06-10 13:28:48.163 16892 16892 I GeckoSession: handleMessage GeckoView:PageStart uri=
06-10 13:28:48.164 16892 16892 D GeckoSession: handleMessage GeckoView:LocationChange uri=about:blank
06-10 13:28:48.164 16892 16892 D GeckoSession: handleMessage GeckoView:PageStop uri=null
06-10 13:28:48.164 16892 16892 I GeckoSession: handleMessage GeckoView:PageStop uri=null

// Logs showing trying to print now
06-10 13:28:48.169 16892 16922 D GeckoViewNavigation: createContentWindowInFrame: uri=null where=4 flags=0 name=null
06-10 13:28:48.169 16892 17131 D sql_support::conn_ext: Transaction commited after 2.831416ms
06-10 13:28:48.171 16892 16922 W GeckoEventDispatcher: No listener for GeckoView:DotPrintRequest

Log observations:
I did see a log of 06-10 13:23:42.351 16892 16922 W GeckoEventDispatcher: No listener for GeckoView:DotPrintRequest which seems particularly interesting.

  • I do see several No listener for xyz.
    • Why didn't GeckoView:DotPrintRequest get registered here?
  • A where of 4 is a print request.
  • I wonder if the uri=null is expected or not? I see an about:blank is launched in Desktop, so maybe.
  • I'm curious if about:blank doesn't register right in custom tabs? Is there a security feature to keep the origin the same?

Can you say more about the JS Print calls on the website?
I'm a bit curious about the Printing JavaScript code, it looked obfuscated to me when I checked on Desktop, could you provide a sample of it? I ask because there are many ways to print and pop-out, and want to narrow down the possibilities. (I have some samples here, for context and code of some different possibilities when printing.).

I have gleaned from Desktop that it the JS is presumably:

  1. Opening about:blank in a new pop-out window
  2. Writing codes to the about:blank page
  3. JS listens for print
    a.) If it printing or closing the print dialog occurs, then close the about:blank page

PWA Exploration
I'm not entirely sure it is purely a custom tab issue because I'm able to print from BMW's PWA using these steps:

  • Go to BMW.com on Android
  • Use Add to Home Screen to add PWA
  • Open PWA
  • May need to set region to BMW USA somewhere
  • Search https://www.bmwusa.com/vehicles/7-series/sedan/core-models.html
    • The result with the printable page is the second result for me
  • Three dot Menu -> Find in Page -> "Print"
  • Click "Print Specifications"
  • Prints as expected

I'd like to know what call the JS is doing to open a new about:blank window, I think that is the best starting point here to start narrowing down the bug.

Flags: needinfo?(ohall) → needinfo?(jonalmeida942)

Searched around and I think I found it:

              , P = function(e) {
                var t = e.value
                  , n = e.contentType
                  , r = e.onAction
                  , i = e.setTooltipVisible
                  , o = e.email
                  , s = (0,
                S.U1)();
                null == n && (n = "Firefox");
                var u = A[n]
                  , c = s.getMsg(u, n)
                  , l = (0,
                a.useCallback)((function() {
                    var e, n = window.open("", "Print", "height=600,width=800");
                    n.document.write(("string" == typeof (e = t) && (e = [e]),
                    "\n    <html>\n    <head><title>".concat(c, "</title></head>\n    <body>\n    ").concat(e.map((function(e) {
                        return "<p>".concat(e, "</p>")
                    }
                    )).join(""), "\n    </body>\n    </html>\n  "))),
                    n.document.close(),
                    n.focus(),
                    n.print(),
                    n.close()
                }

I can make a minimum example off of that.

I'll write a minimum reproducible example this week.

Flags: needinfo?(jonalmeida942) → needinfo?(ohall)
Attached file Bug1899560.html

Test file for the bug, to use call:

adb shell am start -a android.intent.action.VIEW -d "https://bug1899560.bmoattachments.org/attachment.cgi?id=9407569" --ez "android.support.customtabs.extra.SESSION" true

Reproduces the bug in a minimum reproducible example. (Based on the obfuscated JavaScript code on Desktop.)

Flags: needinfo?(ohall)

My instinct from the initial investigation is this isn't a print problem specifically, but an about:blank problem from calling window.open in custom tabs and maybe something to do with how the window opener works. Many items are missing listeners, not only window.print, which shows up under the GeckoView:DotPrintRequest listener.

For this particular use-case, if it is possible to change the print JS code to avoid making an about:blank tab, that is one interim solution. Printing from the same page appears to work in custom tabs. Printing appears to go haywire when there is a window.open JS call building a new tab or window for print and writing content to it. (Some samples of working/non-working print code can be found at adb shell am start -a android.intent.action.VIEW -d "https://ohall-m.github.io/" --ez "android.support.customtabs.extra.SESSION" true The commonality of the samples that do not work in custom tabs are when there is JS code that opens and writes to a new tab before printing.)

Of interest is if Chrome is selected for the intent, the about:blank does not appear and the Print dialog opens, but no content is delivered in the print preview and it has an error. (It appears to work in Chrome correctly if there is not a window.close() call, but the base reproducible example has that call.)

I suspect finding the more universal solution will take time because we will need to investigate the flow of how window.open works in custom tabs.

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

For more information, please visit BugBot documentation.

Flags: needinfo?(jboek)
Severity: -- → S3
Flags: needinfo?(jboek)

Not sure if there is a relation, but bug 1918655 seems semi-related to this bug in terms of debugging window.open and window.close behavior. The solution or research completed on that bug could possibly provide insight into this bug.

See Also: → 1918655

Found out some new information that this bug is related to the custom tabs implementation and not window openers, so removing the association.

See Also: 1918655
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: