Closed Bug 1435880 Opened 3 years ago Closed 3 years ago

Handle moving/detaching tabs between windows when a Payment Request is showing

Categories

(Firefox :: WebPayments UI, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 65
Tracking Status
firefox63 --- disabled
firefox64 --- disabled
firefox65 --- verified

People

(Reporter: MattN, Assigned: MattN)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [webpayments])

Attachments

(6 files, 1 obsolete file)

If a Payment Request tab-modal dialog is showing and the tab is dragged to an existing window or detached to a new window, the Payment Request dialog should continue to be shown in that new window.
Priority: P3 → P2
Whiteboard: [webpayments]
Priority: P2 → P3
Whiteboard: [webpayments] → [webpayments-reserve]
Product: Toolkit → Firefox
Flags: qe-verify?
Priority: P3 → P2
Whiteboard: [webpayments-reserve] → [webpayments]
Flags: qe-verify? → qe-verify+
QA Contact: hani.yacoub
Assignee: nobody → MattN+bmo
Status: NEW → ASSIGNED
Priority: P2 → P1
Remove the intermediate <html:iframe> as it makes support of detaching impossible since we would need
to swap both the <browser> and <html:iframe> contents during a tab detach.
Since a docshell swap requires both docshells to have a frame and document loaded and the move of the
tab won't wait on payments code to do async work to get frames and documents ready for swapping, I
couldn't see a way to get detaching to work with the nested frames.

* Swapping the docshell of only the outer <html:iframe> still caused a reload of the inner <browser>.
Attachment #9021072 - Attachment description: Bug 1435880 - Put the payment dialog <browser> directly in the ChromeWindow. → Bug 1435880 - Put the payment dialog <browser> directly in the ChromeWindow. r=jaws
Attachment #9021075 - Attachment description: Bug 1435880 - Handle moving/detaching tabs between windows when a Payment Request is showing → Bug 1435880 - Handle moving/detaching tabs between windows when a Payment Request is showing. r=jaws,mconley
Properly populate addressLevel3Label in unprivileged-fallbacks.js to not cause l10n.js errors.
Properly populate addressLevel3Label in unprivileged-fallbacks.js to not cause l10n.js errors.
Attachment #9023689 - Attachment is obsolete: true
Attachment #9023681 - Attachment description: Bug 1435880 - Document how to fix Payment Request autofill strings during dev. r=jaws → Bug 1435880 - Document how to fix Payment Request autofill strings during dev. r?jaws
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a3cd9152a9a7
Document how to fix Payment Request autofill strings during dev. r=jaws
Keywords: leave-open
Depends on: 1507251
Keywords: leave-open
Pushed by mozilla@noorenberghe.ca:
https://hg.mozilla.org/integration/autoland/rev/8ae95326b134
Send temporary records in paymentDialogWrapper.initializeFrame. r=sfoster
https://hg.mozilla.org/integration/autoland/rev/802dfe1bb501
Put the payment dialog <browser> directly in the ChromeWindow. r=jaws
https://hg.mozilla.org/integration/autoland/rev/8867eaddfa83
Handle moving/detaching tabs between windows when a Payment Request is showing. r=jaws
https://hg.mozilla.org/integration/autoland/rev/dced0862f4bc
Temporarily disable test_abortPayment and test_canMakePayment due a new leak exposed. r=edenchuang
Verified - Fixed on the latest Nightly 65.0a1 (2018-11-16) (64-bit) on Windows 7/10 x64, Mac OS 10.13 and Ubuntu 16.04.
The Payment Request dialog is shown after moving the tab to a new window.

I also noticed that since this patch landed I can no longer reproduce https://bugzilla.mozilla.org/show_bug.cgi?id=1501285 since the Payment Widget is instantly displayed as it was before. Is this fix also intended?
Status: RESOLVED → VERIFIED
Flags: qe-verify+ → needinfo?(MattN+bmo)
Thanks 

(In reply to Timea Babos from comment #11)
> I also noticed that since this patch landed I can no longer reproduce
> https://bugzilla.mozilla.org/show_bug.cgi?id=1501285 since the Payment
> Widget is instantly displayed as it was before. Is this fix also intended?

I assume you're talking about the delay? I wouldn't be surprised if it was slightly faster to display as there is one less intermediate <iframe> to load. That bug is still relevant to https://rsolomakhin.github.io/pr/wait/ where the merchant is slow to provide the complete Payment Request though.
Flags: needinfo?(MattN+bmo)
Yes, the delay is what I was thinking about. I was about to ask if I should close that one too, but given your additional info, I understood what is it meant for. 

Thanks Matt
Pushed by mozilla@noorenberghe.ca:
https://hg.mozilla.org/integration/autoland/rev/606f30cb7499
Remove stale XUL references from docs along with dead test code.
You need to log in before you can comment on or make changes to this bug.