Bug 203087

Summary: ApplePaySession should never prevent entering the back/forward cache
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: WebCore Misc.Assignee: Andy Estes <aestes>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, aestes, cdumez, commit-queue, ggaren, rniwa, thorton, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 202293    
Attachments:
Description Flags
Patch
none
Patch none

Chris Dumez
Reported 2019-10-17 09:40:25 PDT
ApplePaySession should never prevent entering the back/forward cache.
Attachments
Patch (14.68 KB, patch)
2019-11-04 20:40 PST, Andy Estes
no flags
Patch (10.83 KB, patch)
2019-11-04 21:51 PST, Andy Estes
no flags
Radar WebKit Bug Importer
Comment 1 2019-10-30 08:20:52 PDT
Andy Estes
Comment 2 2019-11-04 20:40:21 PST
Chris Dumez
Comment 3 2019-11-04 20:52:28 PST
Comment on attachment 382805 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=382805&action=review > Source/WebCore/Modules/applepay/ApplePaySession.cpp:831 > +bool ApplePaySession::canSuspendWhileActive() const I find the naming very confusing. How about something like "needsAbortingOnSuspension" ? > Source/WebCore/Modules/applepay/ApplePaySession.cpp:838 > + case State::SuspendedWhileActive: Do we really need a new state? Why not go directly to canceled? > Source/WebCore/Modules/applepay/ApplePaySession.cpp:860 > + // FIXME: Is TaskSource::UserInteraction correct here? I know but it is not the same spec but UserInteraction is what's used in this spec at least: https://w3c.github.io/payment-request/ > Source/WebCore/Modules/applepay/ApplePaySession.cpp:861 > + context.eventLoop().queueTask(TaskSource::UserInteraction, context, [this, pendingActivity = makePendingActivity(*this)] { Why not queue the task in the suspend()? Since you're using the event loop, it would fire until you resume anyway. This way, you don't need a resume() method. Also, you should consider using ActiveDOMObject::queueTaskKeepingObjectAlive() instead to queue the task.
Chris Dumez
Comment 4 2019-11-04 20:53:28 PST
(In reply to Chris Dumez from comment #3) > Comment on attachment 382805 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=382805&action=review > > > Source/WebCore/Modules/applepay/ApplePaySession.cpp:831 > > +bool ApplePaySession::canSuspendWhileActive() const > > I find the naming very confusing. How about something like > "needsAbortingOnSuspension" ? > > > Source/WebCore/Modules/applepay/ApplePaySession.cpp:838 > > + case State::SuspendedWhileActive: > > Do we really need a new state? Why not go directly to canceled? > > > Source/WebCore/Modules/applepay/ApplePaySession.cpp:860 > > + // FIXME: Is TaskSource::UserInteraction correct here? > > I know but it is not the same spec but UserInteraction is what's used in > this spec at least: https://w3c.github.io/payment-request/ > > > Source/WebCore/Modules/applepay/ApplePaySession.cpp:861 > > + context.eventLoop().queueTask(TaskSource::UserInteraction, context, [this, pendingActivity = makePendingActivity(*this)] { > > Why not queue the task in the suspend()? Since you're using the event loop, > it would fire until you resume anyway. This way, you don't need a resume() > method. it would *NOT* fire until you resume anyway
Andy Estes
Comment 5 2019-11-04 21:51:00 PST
Chris Dumez
Comment 6 2019-11-05 08:12:51 PST
Comment on attachment 382806 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=382806&action=review > Source/WebCore/Modules/applepay/ApplePaySession.cpp:866 > + queueTaskToDispatchEvent(*this, TaskSource::UserInteraction, ApplePayCancelEvent::create(eventNames().cancelEvent, { })); nice.
WebKit Commit Bot
Comment 7 2019-11-05 09:13:08 PST
Comment on attachment 382806 [details] Patch Clearing flags on attachment: 382806 Committed r252057: <https://trac.webkit.org/changeset/252057>
WebKit Commit Bot
Comment 8 2019-11-05 09:13:10 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.