Closed Bug 1435880 Opened 6 years ago Closed 6 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.

Attachment

General

Created:
Updated:
Size: