RESOLVED FIXED 189801
WebSQL: User cannot grant quota increase if the JS provides an expected usage value that is too low
https://bugs.webkit.org/show_bug.cgi?id=189801
Summary WebSQL: User cannot grant quota increase if the JS provides an expected usage...
Chris Dumez
Reported 2018-09-20 13:33:30 PDT
User cannot grant quota increase for WebSQL if the JS provides an expected usage value that is too low.
Attachments
Patch (7.69 KB, patch)
2018-09-20 13:39 PDT, Chris Dumez
no flags
Archive of layout-test-results from ews102 for mac-sierra (2.53 MB, application/zip)
2018-09-20 14:48 PDT, EWS Watchlist
no flags
Patch (7.77 KB, patch)
2018-09-20 15:55 PDT, Chris Dumez
no flags
Patch (7.97 KB, patch)
2018-09-21 10:47 PDT, Chris Dumez
no flags
Patch (7.97 KB, patch)
2018-09-21 11:03 PDT, Chris Dumez
no flags
Patch (9.76 KB, patch)
2018-09-21 11:52 PDT, Chris Dumez
no flags
Patch (14.07 KB, patch)
2018-09-21 12:13 PDT, Chris Dumez
no flags
Patch (14.11 KB, patch)
2018-09-21 12:18 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2018-09-20 13:33:46 PDT
Chris Dumez
Comment 2 2018-09-20 13:39:44 PDT
EWS Watchlist
Comment 3 2018-09-20 14:48:16 PDT
Comment on attachment 350258 [details] Patch Attachment 350258 [details] did not pass mac-ews (mac): Output: https://webkit-queues.webkit.org/results/9286897 New failing tests: storage/websql/transaction-database-expand-quota.html
EWS Watchlist
Comment 4 2018-09-20 14:48:17 PDT
Created attachment 350267 [details] Archive of layout-test-results from ews102 for mac-sierra The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews102 Port: mac-sierra Platform: Mac OS X 10.12.6
Geoffrey Garen
Comment 5 2018-09-20 15:22:47 PDT
Regressions: Unexpected text-only failures (1) storage/websql/transaction-database-expand-quota.html [ Failure ]
Chris Dumez
Comment 6 2018-09-20 15:53:33 PDT
(In reply to Geoffrey Garen from comment #5) > Regressions: Unexpected text-only failures (1) > storage/websql/transaction-database-expand-quota.html [ Failure ] Yes, WK1 ignores the estimatedSize parameter and gets it from the DatabaseTracker instead. I will have a fix shortly.
Chris Dumez
Comment 7 2018-09-20 15:55:28 PDT
youenn fablet
Comment 8 2018-09-21 09:38:09 PDT
Comment on attachment 350275 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=350275&action=review > Source/WebCore/Modules/webdatabase/Database.cpp:797 > + if (estimatedSize() <= oldQuota) { Is the name oldQuota misleading? It seems like oldQuota is the current database size while estimatedSize is the 'quota' defined by the page. > Source/WebCore/Modules/webdatabase/Database.cpp:800 > + setEstimatedSize(oldQuota + 5 * 1024. * 1024.); Should we move this as a macro with a name like QUOTA_SIZE_INCREMENT? > Source/WebCore/Modules/webdatabase/Database.h:92 > + void setEstimatedSize(unsigned); Can we make setEstimatedSize private? And maybe estimatedSize as well.
Chris Dumez
Comment 9 2018-09-21 10:04:48 PDT
Comment on attachment 350275 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=350275&action=review >> Source/WebCore/Modules/webdatabase/Database.cpp:797 >> + if (estimatedSize() <= oldQuota) { > > Is the name oldQuota misleading? > It seems like oldQuota is the current database size while estimatedSize is the 'quota' defined by the page. I think oldQuota is correct. It is really the current quota. However, because we now we exceeded the quota, we know the database size has reached the quota. >> Source/WebCore/Modules/webdatabase/Database.cpp:800 >> + setEstimatedSize(oldQuota + 5 * 1024. * 1024.); > > Should we move this as a macro with a name like QUOTA_SIZE_INCREMENT? If you mean a quotaSizeIncrement global variable, then yes. >> Source/WebCore/Modules/webdatabase/Database.h:92 >> + void setEstimatedSize(unsigned); > > Can we make setEstimatedSize private? > And maybe estimatedSize as well. Certainly.
Chris Dumez
Comment 10 2018-09-21 10:47:35 PDT
Chris Dumez
Comment 11 2018-09-21 11:03:26 PDT
Chris Dumez
Comment 12 2018-09-21 11:52:58 PDT
Chris Dumez
Comment 13 2018-09-21 12:13:13 PDT
Chris Dumez
Comment 14 2018-09-21 12:18:03 PDT
WebKit Commit Bot
Comment 15 2018-09-21 12:59:49 PDT
Comment on attachment 350401 [details] Patch Clearing flags on attachment: 350401 Committed r236348: <https://trac.webkit.org/changeset/236348>
WebKit Commit Bot
Comment 16 2018-09-21 12:59:51 PDT
All reviewed patches have been landed. Closing bug.
Truitt Savell
Comment 17 2018-09-21 15:54:55 PDT
Chris Dumez
Comment 18 2018-09-21 16:02:56 PDT
(In reply to Truitt Savell from comment #17) > Looks like the new test added in > https://trac.webkit.org/changeset/236348/webkit > > is a flakey timeout: storage/websql/transaction-database-expand-quota.html > > History: > https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard. > html#showAllRuns=true&tests=storage%2Fwebsql%2Ftransaction-database-expand- > quota.html Looking...
Chris Dumez
Comment 19 2018-09-21 16:11:32 PDT
(In reply to Chris Dumez from comment #18) > (In reply to Truitt Savell from comment #17) > > Looks like the new test added in > > https://trac.webkit.org/changeset/236348/webkit > > > > is a flakey timeout: storage/websql/transaction-database-expand-quota.html > > > > History: > > https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard. > > html#showAllRuns=true&tests=storage%2Fwebsql%2Ftransaction-database-expand- > > quota.html > > Looking... I think the test is just slow in debug because of constructing the 8MB array. I'll see how I can speed it up.
Chris Dumez
Comment 20 2018-09-21 16:19:31 PDT
(In reply to Chris Dumez from comment #19) > (In reply to Chris Dumez from comment #18) > > (In reply to Truitt Savell from comment #17) > > > Looks like the new test added in > > > https://trac.webkit.org/changeset/236348/webkit > > > > > > is a flakey timeout: storage/websql/transaction-database-expand-quota.html > > > > > > History: > > > https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard. > > > html#showAllRuns=true&tests=storage%2Fwebsql%2Ftransaction-database-expand- > > > quota.html > > > > Looking... > > I think the test is just slow in debug because of constructing the 8MB > array. I'll see how I can speed it up. Sped up the test in <https://trac.webkit.org/changeset/236370> by using a much smaller array.
Note You need to log in before you can comment on or make changes to this bug.