RESOLVED FIXED 40002
Need Geolocation LayoutTest to test case where permission has neither been granted nor denied
https://bugs.webkit.org/show_bug.cgi?id=40002
Summary Need Geolocation LayoutTest to test case where permission has neither been gr...
Steve Block
Reported 2010-06-01 08:48:01 PDT
We need a Geolocation LayoutTest to test the case where a position is available but the embedder has not yet either granted or denied permission. In this case, no callback should be made.
Attachments
Patch (6.17 KB, patch)
2010-06-01 09:42 PDT, Steve Block
no flags
Patch (15.35 KB, patch)
2010-06-07 08:35 PDT, Steve Block
no flags
Patch (16.56 KB, patch)
2010-07-27 09:48 PDT, Steve Block
no flags
Patch (16.52 KB, patch)
2010-08-03 09:28 PDT, Steve Block
no flags
Patch (16.57 KB, patch)
2010-08-03 10:56 PDT, Steve Block
steveblock: review+
steveblock: commit-queue-
Steve Block
Comment 1 2010-06-01 09:42:46 PDT
Alexey Proskuryakov
Comment 2 2010-06-01 10:51:57 PDT
Comment on attachment 57553 [details] Patch I guess I'm missing something, but I don't see how this test can work. All LayoutTestController::setGeolocationPermission() does is set a member variable, how does this result in async callback?
Steve Block
Comment 3 2010-06-07 08:33:28 PDT
(In reply to comment #2) > (From update of attachment 57553 [details]) > I guess I'm missing something, but I don't see how this test can work. Sorry, I was testing with the Android LayoutTestController, which isn't upstream, and forgot to update the common LayoutTestController. Updating patch coming.
Steve Block
Comment 4 2010-06-07 08:35:13 PDT
Alexey Proskuryakov
Comment 5 2010-06-07 08:56:38 PDT
Comment on attachment 58033 [details] Patch + assert(m_pendingGeolocationPermissionListener == nil); Should be "ASSERT(!m_pendingGeolocationPermissionListener)". + if (m_pendingGeolocationPermissionListener == nil) Should be "if (!m_pendingGeolocationPermissionListener)". + if (allow) + [m_pendingGeolocationPermissionListener allow]; + else + [m_pendingGeolocationPermissionListener deny]; + + [m_pendingGeolocationPermissionListener release]; + m_pendingGeolocationPermissionListener = nil; This calls out from DRT code, so UIDelegate may be released in the meanwhile. I'd use a local variable for the listener. + if (!_timer) + _timer = [NSTimer scheduledTimerWithTimeInterval:0 target:self selector:@selector(timerFired) userInfo:0 repeats:NO]; I don't understand this change. Ideally, the allow/deny callback should be completely asynchronous (and not dispatched from setGeolocationPermission() directly), but this change doesn't give us that. Is this what you refer to as "minor fix" in the ChangeLog? +- (void)setGeolocationPermission:(bool)allow It's somewhat confusing to have a function with such a generic name in UI delegate. Something like "setMockGeolocationOErmission" can help avoid the confusion. + // FIXME: Implement for Geolocation layout tests. Does the new test need to be skipped on Gtk? I think that this could use another review round, especially if you decide to implement true asynchronicity.
Steve Block
Comment 6 2010-06-07 10:19:38 PDT
Thanks for the review Alexey. > This calls out from DRT code, so UIDelegate may be released in the meanwhile. > I'd use a local variable for the listener. I'm not sure I understand. When would the UI delegate be released while script is still running? > + if (!_timer) > + _timer = [NSTimer scheduledTimerWithTimeInterval:0 target:self selector:@selector(timerFired) userInfo:0 repeats:NO]; > > I don't understand this change. Ideally, the allow/deny callback should be > completely asynchronous (and not dispatched from setGeolocationPermission() > directly), but this change doesn't give us that. Is this what you refer to as > "minor fix" in the ChangeLog? This change is the "minor fix". Previously, the MockGeolocationProvider didn't trigger a position update to the WebView when it registered - only when a new mock position was set. It relied on the fact that the WebView was registered synchronously along with the call to set the mock position. So by the time the MockGeolocationProvider's timer fired, the Webview was registered and it would be sent the position. Now that the permission is granted asynchronously, the WebView is also added asynchronously (Geolocation does not call startUpdating() until permission is granted). So there's a race condition and the timer may fire before the WebView is registered. This change makes sure that the WebView gets the position when it registers. I think the above change is independent of whether the allow/deny callback is completely asynchronous. Is there a particular need for it to be completely asynchronous?
Alexey Proskuryakov
Comment 7 2010-06-08 09:58:28 PDT
> > This calls out from DRT code, so UIDelegate may be released in the meanwhile. > > I'd use a local variable for the listener. > I'm not sure I understand. When would the UI delegate be released while script is still running? I haven't looked into the details, maybe WebKit can navigate away from the current page during this callback. It's always best not to rely on behavior of delegate calls made into different projects. > I think the above change is independent of whether the allow/deny callback is completely > asynchronous. Is there a particular need for it to be completely asynchronous? Nothing particular I can think of, just matching "real life" code path better. > This change is the "minor fix". OK. It would be nice to say a few words about this in ChangeLog.
Steve Block
Comment 8 2010-07-27 09:48:03 PDT
Alexey Proskuryakov
Comment 9 2010-08-02 02:46:55 PDT
Comment on attachment 62699 [details] Patch + [[[mainFrame webView] UIDelegate] didSetGeolocationPermission]; I'd still prefer this to be called didSetMockGeolocationPermission (same for a few other names, of course) . It's hard to understand the various permissions here, so being specific helps. + HashSet<id<WebGeolocationPolicyListener> > m_pendingGeolocationPermissionListeners; This code is fine in the short run, but HashSet isn't a great data structure to keep Objective-C objects in. Specifically, we'll get problems if we try to run DumpRenderTree in garbage collected mode. NSMutableSet is the easiest way to make the code more clean. r=me, but please consider addressing these comments.
Darin Adler
Comment 10 2010-08-02 10:12:11 PDT
(In reply to comment #9) > NSMutableSet is the easiest way to make the code more clean. Or perhaps NSMapTable.
Steve Block
Comment 11 2010-08-03 09:28:15 PDT
Alexey Proskuryakov
Comment 12 2010-08-03 10:28:58 PDT
Comment on attachment 63340 [details] Patch +#import <Foundation/NSSet.h> This isn't needed, please don't add this line. + if (m_pendingGeolocationPermissionListeners != nil && !m_timer) We don't compare to null, so this can be just (m_pendingGeolocationPermissionListeners && !m_timer) + if (!m_pendingGeolocationPermissionListeners) + m_pendingGeolocationPermissionListeners = [[NSMutableSet set] retain]; I see that m_pendingGeolocationPermissionListeners is released in timerFired, but shouldn't it be also released in dealloc method - in case the timer doesn't get a chance to fire? + NSEnumerator* enumerator = [m_pendingGeolocationPermissionListeners objectEnumerator]; Should we be iterating a copy? It seems that a client might add listeners when handling allow/deny. r=me
Steve Block
Comment 13 2010-08-03 10:47:50 PDT
> This isn't needed, please don't add this line. Will fix > We don't compare to null, so this can be just (m_pendingGeolocationPermissionListeners && !m_timer) Will fix > I see that m_pendingGeolocationPermissionListeners is released in timerFired, but shouldn't it be also released in dealloc method - in case the timer doesn't get a chance to fire? Yes, will fix > Should we be iterating a copy? It seems that a client might add listeners when handling allow/deny. No, because listeners are only added before permission has been set. But when the timer fires, the permission must have already been set, as in the assertion above
Steve Block
Comment 14 2010-08-03 10:56:31 PDT
Steve Block
Comment 15 2010-08-03 10:57:15 PDT
Comment on attachment 63353 [details] Patch New patch to check build on EWS bots.
Steve Block
Comment 16 2010-08-03 12:44:25 PDT
Comment on attachment 63353 [details] Patch Minor changes only since Alexey's r+
Steve Block
Comment 17 2010-08-04 04:10:49 PDT
Comment on attachment 63353 [details] Patch Giving up on commit queue, which seems to be having problems. Will land manually.
Steve Block
Comment 18 2010-08-04 04:15:54 PDT
Landed manually as http://trac.webkit.org/changeset/64639 Closing as resolved fixed.
WebKit Review Bot
Comment 19 2010-08-04 04:32:08 PDT
http://trac.webkit.org/changeset/64639 might have broken Qt Linux Release
Steve Block
Comment 20 2010-08-04 04:39:53 PDT
> http://trac.webkit.org/changeset/64639 might have broken Qt Linux Release Added new tests to Qt skipped list with http://trac.webkit.org/changeset/64640
Simon Hausmann
Comment 21 2010-08-25 03:01:22 PDT
<cherry-pick-for-backport: r64639>
Simon Hausmann
Comment 22 2010-08-25 03:01:35 PDT
<cherry-pick-for-backport: r64640>
Simon Hausmann
Comment 23 2010-08-25 06:18:20 PDT
Revision r64639 cherry-picked into qtwebkit-2.1 with commit 741b9a8007571c1a8907f4de91f7dd9f6b3c345e Revision r64640 cherry-picked into qtwebkit-2.1 with commit 51fa56069c38a406e86170dd764d6ce90d6d1a5a found f81dde5b7304f9389b876c60ba5843774e3e7a02
Note You need to log in before you can comment on or make changes to this bug.