[Webkit-unassigned] [Bug 203431] REGRESSION (r250754): web page using IDBIndex doesn't load occasionally

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=203431

--- Comment #5 from Chris Dumez <cdumez at apple.com> ---
(In reply to Sihui Liu from comment #4)
> (In reply to Sihui Liu from comment #3)
> > (In reply to Chris Dumez from comment #2)
> > > (In reply to Sihui Liu from comment #1)
> > > > Adding shouldPreventEnteringBackForwardCache_DEPRECATED() to return true in
> > > > IDBIndex fixes the issue.
> > > 
> > > This would not the right fix though, just to be clear.
> > 
> > The cause is the IDBDatabase object is not destroyed and database connection
> > stays open when user navigates to another page. When the second page tries
> > to delete the database, it's blocked on the open connection.
> > 
> > We have to close database connections on navigation, and this would change
> > the state of the IDB DOM objects (open connection -> closed, ongoing
> > transaction -> aborted, etc). If the state change is acceptable for page
> > cache, we probably stop()/close() the IDBDatabase in suspend().
> 
> Or maybe to invalidate the IDB objects when there are IDB changes from the
> new page, and discard page cache when there are invalidated IDB objects

We need to be careful about Web compatibility.

I looked at the spec and found:
"""
A connection may be closed by a user agent in exceptional circumstances, for example due to loss of access to the file system, a permission change, or clearing of the origin’s storage. If this occurs the user agent must run close a database connection with the connection and with the forced flag set to true.
"""

It looks like "close a database connection" algorithm fires a "close" event so I guess the page would at least get notified on resume that the connection was closed and could re-open it itself.

Ideally though, the Web page would not have to do anything and things would recover nicely by themselves upon resuming. That said, I have no idea if it is feasible here.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191026/77d96030/attachment-0001.htm>