RESOLVED FIXED 117333
Vibration can be canceled even if page visibility status is hidden
https://bugs.webkit.org/show_bug.cgi?id=117333
Summary Vibration can be canceled even if page visibility status is hidden
Kihong Kwon
Reported 2013-06-07 00:42:53 PDT
cancelVibration can be called in the visibilitychange listener even if page visibility is changed to hidden. Therefore cancelVibration have to work when page visibility is hidden.
Attachments
Patch (1.63 KB, patch)
2013-06-07 00:56 PDT, Kihong Kwon
no flags
Patch (10.96 KB, patch)
2013-06-13 03:26 PDT, Kihong Kwon
no flags
Patch (10.75 KB, patch)
2013-06-13 04:09 PDT, Kihong Kwon
no flags
Archive of layout-test-results from webkit-ews-03 for mac-mountainlion (727.20 KB, application/zip)
2013-06-13 08:11 PDT, Build Bot
no flags
Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2 (797.44 KB, application/zip)
2013-06-13 11:44 PDT, Build Bot
no flags
Patch (13.28 KB, patch)
2013-06-13 18:21 PDT, Kihong Kwon
no flags
Patch (13.28 KB, patch)
2013-06-13 23:31 PDT, Kihong Kwon
no flags
Patch (13.18 KB, patch)
2013-06-14 04:11 PDT, Kihong Kwon
no flags
Kihong Kwon
Comment 1 2013-06-07 00:56:47 PDT
Chris Dumez
Comment 2 2013-06-07 05:58:37 PDT
Comment on attachment 204010 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=204010&action=review > Source/WebCore/ChangeLog:11 > + No new tests, covered by existing tests. It is not covered by existing tests, otherwise tests would be unskipped / rebaselined with this fix. I believe you need a layout test.
Kihong Kwon
Comment 3 2013-06-07 06:45:21 PDT
(In reply to comment #2) > (From update of attachment 204010 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=204010&action=review > > > Source/WebCore/ChangeLog:11 > > + No new tests, covered by existing tests. > > It is not covered by existing tests, otherwise tests would be unskipped / rebaselined with this fix. I believe you need a layout test. IMHO, we couldn't make more test cases for vibration api, because is is only for signal to the device and no response or return value for checking.
Chris Dumez
Comment 4 2013-06-07 07:01:55 PDT
(In reply to comment #3) > (In reply to comment #2) > > (From update of attachment 204010 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=204010&action=review > > > > > Source/WebCore/ChangeLog:11 > > > + No new tests, covered by existing tests. > > > > It is not covered by existing tests, otherwise tests would be unskipped / rebaselined with this fix. I believe you need a layout test. > > IMHO, we couldn't make more test cases for vibration api, because is is only for signal to the device and no response or return value for checking. Actually, I believe this is currently a signal to the browser. What prevents you from extending DRT / WKTR and dump information when cancelVibration is called?
Kihong Kwon
Comment 5 2013-06-13 03:26:29 PDT
Early Warning System Bot
Comment 6 2013-06-13 03:34:01 PDT
Early Warning System Bot
Comment 7 2013-06-13 03:44:03 PDT
Kihong Kwon
Comment 8 2013-06-13 04:09:13 PDT
Build Bot
Comment 9 2013-06-13 08:11:07 PDT
Comment on attachment 204571 [details] Patch Attachment 204571 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/850143 New failing tests: vibration/navigator-vibration.html fast/repaint/table-cell-collapsed-border-scroll.html vibration/cancelVibration-after-pagevisibility-changed-to-hidden.html
Build Bot
Comment 10 2013-06-13 08:11:11 PDT
Created attachment 204586 [details] Archive of layout-test-results from webkit-ews-03 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-03 Port: mac-mountainlion Platform: Mac OS X 10.8.3
Build Bot
Comment 11 2013-06-13 11:44:28 PDT
Comment on attachment 204571 [details] Patch Attachment 204571 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/893020 New failing tests: vibration/navigator-vibration.html vibration/cancelVibration-after-pagevisibility-changed-to-hidden.html
Build Bot
Comment 12 2013-06-13 11:44:32 PDT
Created attachment 204635 [details] Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-15 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.3
Kihong Kwon
Comment 13 2013-06-13 18:21:00 PDT
Gyuyoung Kim
Comment 14 2013-06-13 18:59:42 PDT
Comment on attachment 204659 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=204659&action=review > Source/WebCore/ChangeLog:9 > + Therefore cancelVibration need to work when page visibility is hidden. need -> needs ? > Source/WebCore/Modules/vibration/NavigatorVibration.cpp:48 > + if (navigator->frame()->page()->visibilityState() == PageVisibilityStateHidden && time) Can't we use Vibration::isActive() instead of time in order to check if vibration is live ? > Source/WebCore/testing/Internals.cpp:2169 > +bool Internals::isVibrating() Don't you need to use ExceptionCode ?
Kihong Kwon
Comment 15 2013-06-13 19:17:40 PDT
(In reply to comment #14) > (From update of attachment 204659 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=204659&action=review > > > Source/WebCore/Modules/vibration/NavigatorVibration.cpp:48 > > + if (navigator->frame()->page()->visibilityState() == PageVisibilityStateHidden && time) > > Can't we use Vibration::isActive() instead of time in order to check if vibration is live ? If time is 0, vibration api works to cancel vibration. It is different from isActive status. > > > Source/WebCore/testing/Internals.cpp:2169 > > +bool Internals::isVibrating() > > Don't you need to use ExceptionCode ? I don't think I need ExceptionCode here. Important thing of isVibrating is vibrating or not currently. Therefore "return false" which is in the if-statement is enough to check that.
Kihong Kwon
Comment 16 2013-06-13 23:31:34 PDT
Gyuyoung Kim
Comment 17 2013-06-14 00:11:33 PDT
Comment on attachment 204676 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=204676&action=review > Source/WebCore/testing/Internals.cpp:2175 > + return Vibration::from(document->domWindow()->navigator()->frame()->page())->isVibrating(); You misses to check if page() is null or not. BTW, should you get a page instance by navigator() ? IMHO, navigator has been used in NavigatorXXX mainly.
Kihong Kwon
Comment 18 2013-06-14 01:08:06 PDT
(In reply to comment #17) > (From update of attachment 204676 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=204676&action=review > > > Source/WebCore/testing/Internals.cpp:2175 > > + return Vibration::from(document->domWindow()->navigator()->frame()->page())->isVibrating(); > > You misses to check if page() is null or not. BTW, should you get a page instance by navigator() ? IMHO, navigator has been used in NavigatorXXX mainly. Vibration instance is attached to Supplement<Page>, therefore we can get an instance of Vibration by document.page(); In this case, I think document->page() is enough to get a page instance. In addition, navigator doesn't have page pointer, that's why I used "navigator()->frame()->page()" I will change from "document->domWindow()->navigator()->frame()->page()" to "document->page()" And I will check if page is null or not using ASSERT.
Kihong Kwon
Comment 19 2013-06-14 04:11:54 PDT
Gyuyoung Kim
Comment 20 2013-06-17 19:28:27 PDT
Comment on attachment 204698 [details] Patch LGTM. But, someone else might wanna have a final look.
Kihong Kwon
Comment 21 2013-06-18 18:05:58 PDT
If there is no more comment, I will land this today. Thanks Gyuyoung.
WebKit Commit Bot
Comment 22 2013-06-19 01:07:59 PDT
Comment on attachment 204698 [details] Patch Clearing flags on attachment: 204698 Committed r151727: <http://trac.webkit.org/changeset/151727>
WebKit Commit Bot
Comment 23 2013-06-19 01:08:05 PDT
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.