WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(15.35 KB, patch)
2010-06-07 08:35 PDT
,
Steve Block
no flags
Details
Formatted Diff
Diff
Patch
(16.56 KB, patch)
2010-07-27 09:48 PDT
,
Steve Block
no flags
Details
Formatted Diff
Diff
Patch
(16.52 KB, patch)
2010-08-03 09:28 PDT
,
Steve Block
no flags
Details
Formatted Diff
Diff
Patch
(16.57 KB, patch)
2010-08-03 10:56 PDT
,
Steve Block
steveblock
: review+
steveblock
: commit-queue-
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Steve Block
Comment 1
2010-06-01 09:42:46 PDT
Created
attachment 57553
[details]
Patch
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
Created
attachment 58033
[details]
Patch
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
Created
attachment 62699
[details]
Patch
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
Created
attachment 63340
[details]
Patch
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
Created
attachment 63353
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug