<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>26993</bug_id>
          
          <creation_ts>2009-07-06 09:11:51 -0700</creation_ts>
          <short_desc>Geolocation::requestPermission()</short_desc>
          <delta_ts>2009-08-12 17:14:35 -0700</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>WebCore Misc.</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>All</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          <blocked>27853</blocked>
          <everconfirmed>1</everconfirmed>
          <reporter name="Yong Li">yong.li.webkit</reporter>
          <assigned_to name="Steve Block">steveblock</assigned_to>
          <cc>abarth</cc>
    
    <cc>bolsinga</cc>
    
    <cc>darin</cc>
    
    <cc>eric</cc>
    
    <cc>sam</cc>
    
    <cc>skyul</cc>
    
    <cc>staikos</cc>
    
    <cc>steveblock</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>129959</commentid>
    <comment_count>0</comment_count>
    <who name="Yong Li">yong.li.webkit</who>
    <bug_when>2009-07-06 09:11:51 -0700</bug_when>
    <thetext>See the following code:

void Geolocation::requestPermission()
{
    ......

    // Ask the chrome: it maintains the geolocation challenge policy itself.
    page-&gt;chrome()-&gt;requestGeolocationPermissionForFrame(m_frame, this);
    
    m_allowGeolocation = InProgress;
}

And the only case that requestPermission() is called:

void Geolocation::geolocationServicePositionChanged(GeolocationService* service)
{
    ASSERT(service-&gt;lastPosition());
    
    requestPermission();
    if (!isAllowed())
        return;

    ......
}

This is weird. Whatever Chrome::requestGeolocationPermissionForFrame() does on the Geolocation object, m_allowGeolocation is always InProgress. Unless it calls setAllowed by a timer. So as the result, the first call to geolocationServicePositionChanged must fail, and the subsequent calls can succeed only after the ChromeClient calls setIsAllowed(true) by a timer.

Why not change it to:

    m_allowGeolocation = InProgress;
    page-&gt;chrome()-&gt;requestGeolocationPermissionForFrame(m_frame, this);

Is it any reason for it?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>135243</commentid>
    <comment_count>1</comment_count>
    <who name="Yong Li">yong.li.webkit</who>
    <bug_when>2009-07-28 09:15:34 -0700</bug_when>
    <thetext>
The patch:

--- a/WebCore/page/Geolocation.cpp
+++ b/WebCore/page/Geolocation.cpp
@@ -1,5 +1,6 @@
 /*
  * Copyright (C) 2008, 2009 Apple Inc. All Rights Reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -264,10 +265,10 @@ void Geolocation::requestPermission()
     if (!page)
         return;

+    m_allowGeolocation = InProgress;
+
     // Ask the chrome: it maintains the geolocation challenge policy itself.
     page-&gt;chrome()-&gt;requestGeolocationPermissionForFrame(m_frame, this);
-    
-    m_allowGeolocation = InProgress;
 }</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>135315</commentid>
    <comment_count>2</comment_count>
      <attachid>33659</attachid>
    <who name="Yong Li">yong.li.webkit</who>
    <bug_when>2009-07-28 12:10:38 -0700</bug_when>
    <thetext>Created attachment 33659
the patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>136035</commentid>
    <comment_count>3</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2009-07-30 14:57:32 -0700</bug_when>
    <thetext>*** Bug 27853 has been marked as a duplicate of this bug. ***</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>136051</commentid>
    <comment_count>4</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2009-07-30 15:32:48 -0700</bug_when>
    <thetext>Is this testable somehow?  It would be easy to test with a LayoutTest, but I&apos;m not sure how we could test it with a LayoutTest...</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>136080</commentid>
    <comment_count>5</comment_count>
      <attachid>33659</attachid>
    <who name="Adam Barth">abarth</who>
    <bug_when>2009-07-30 18:29:29 -0700</bug_when>
    <thetext>Comment on attachment 33659
the patch

Let me know if you figure out a way to test this.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>136082</commentid>
    <comment_count>6</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2009-07-30 18:30:03 -0700</bug_when>
    <thetext>You also might consider adding more explanation to the ChangeLog.  :)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>136095</commentid>
    <comment_count>7</comment_count>
    <who name="Yong Li">yong.li.webkit</who>
    <bug_when>2009-07-30 19:56:46 -0700</bug_when>
    <thetext>(In reply to comment #6)
&gt; You also might consider adding more explanation to the ChangeLog.  :)

Thanks!</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>136261</commentid>
    <comment_count>8</comment_count>
    <who name="Greg Bolsinga">bolsinga</who>
    <bug_when>2009-07-31 15:07:19 -0700</bug_when>
    <thetext>Were you able to test this out? I&apos;d have to do quite a bit of work to get my port back to this asynchronous mode to test it out. Thanks!</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>136421</commentid>
    <comment_count>9</comment_count>
      <attachid>33659</attachid>
    <who name="Adam Barth">abarth</who>
    <bug_when>2009-07-31 23:43:28 -0700</bug_when>
    <thetext>Comment on attachment 33659
the patch

Clearing review flag on attachment: 33659

Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	WebCore/ChangeLog
	M	WebCore/page/Geolocation.cpp
Committed r46663
	M	WebCore/ChangeLog
	M	WebCore/page/Geolocation.cpp
r46663 = 652e8a6a543e021b653c175b4640f6d8fa392af3 (trunk)
No changes between current HEAD and refs/remotes/trunk
Resetting to the latest refs/remotes/trunk
http://trac.webkit.org/changeset/46663</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>136422</commentid>
    <comment_count>10</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2009-07-31 23:43:32 -0700</bug_when>
    <thetext>All reviewed patches have been landed.  Closing bug.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>137583</commentid>
    <comment_count>11</comment_count>
    <who name="Steve Block">steveblock</who>
    <bug_when>2009-08-06 09:01:48 -0700</bug_when>
    <thetext>If I&apos;ve followed the comments correctly, this change is intended to support both synchronous and asynchronous implementations of requestGeolocationPermissionForFrame().

I think, however, that this patch introduces a bug in the case where requestGeolocationPermissionForFrame() is synchronous. setIsAllowed() calls geolocationServicePositionChanged(), so if requestGeolocationPermissionForFrame() is synchronous, any watches will be called back twice, rather than once as intended.

See https://bugs.webkit.org/show_bug.cgi?id=27690 (which is a duplicate of this bug) for a full explanation.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>137584</commentid>
    <comment_count>12</comment_count>
    <who name="Yong Li">yong.li.webkit</who>
    <bug_when>2009-08-06 09:08:19 -0700</bug_when>
    <thetext>(In reply to comment #11)
&gt; If I&apos;ve followed the comments correctly, this change is intended to support
&gt; both synchronous and asynchronous implementations of
&gt; requestGeolocationPermissionForFrame().
&gt; 
&gt; I think, however, that this patch introduces a bug in the case where
&gt; requestGeolocationPermissionForFrame() is synchronous. setIsAllowed() calls
&gt; geolocationServicePositionChanged(), so if
&gt; requestGeolocationPermissionForFrame() is synchronous, any watches will be
&gt; called back twice, rather than once as intended.
&gt; 
&gt; See https://bugs.webkit.org/show_bug.cgi?id=27690 (which is a duplicate of this
&gt; bug) for a full explanation.

I don&apos;t think it&apos;s a problem, because:

void Geolocation::requestPermission()
{
    if (m_allowGeolocation &gt; Unknown)
        return;

...</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>137588</commentid>
    <comment_count>13</comment_count>
    <who name="Steve Block">steveblock</who>
    <bug_when>2009-08-06 09:33:32 -0700</bug_when>
    <thetext>&gt; I don&apos;t think it&apos;s a problem, because:
I&apos;m pretty sure it is a problem. You&apos;re right that the check on m_allowGeolocation in requestPermission() will prevent repeated calls to requestGeolocationPermissionForFrame(), but there will still be repeated callbacks to watchers.

The first callbacks are made when the call stack is ...
geolocationServicePositionChanged() -&gt; requestPermission() -&gt; requestGeolocationPermissionForFrame() -&gt; setIsAllowed() -&gt; geolocationServicePositionChanged()

The stack then unwinds to ...
geolocationServicePositionChanged()
and the callbacks are made a second time.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>137589</commentid>
    <comment_count>14</comment_count>
    <who name="Yong Li">yong.li.webkit</who>
    <bug_when>2009-08-06 09:38:07 -0700</bug_when>
    <thetext>(In reply to comment #13)
&gt; &gt; I don&apos;t think it&apos;s a problem, because:
&gt; I&apos;m pretty sure it is a problem. You&apos;re right that the check on
&gt; m_allowGeolocation in requestPermission() will prevent repeated calls to
&gt; requestGeolocationPermissionForFrame(), but there will still be repeated
&gt; callbacks to watchers.
&gt; 
&gt; The first callbacks are made when the call stack is ...
&gt; geolocationServicePositionChanged() -&gt; requestPermission() -&gt;
&gt; requestGeolocationPermissionForFrame() -&gt; setIsAllowed() -&gt;
&gt; geolocationServicePositionChanged()
&gt; 
&gt; The stack then unwinds to ...
&gt; geolocationServicePositionChanged()
&gt; and the callbacks are made a second time.

I see. It sends current position twice.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>137591</commentid>
    <comment_count>15</comment_count>
    <who name="Steve Block">steveblock</who>
    <bug_when>2009-08-06 09:43:20 -0700</bug_when>
    <thetext>&gt; I see. It sends current position twice.
Indeed. I&apos;ll send a patch to fix this if somebody can review it.

Can somebody also reopen this bug and mark Bug 27690 as a duplicate?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>137592</commentid>
    <comment_count>16</comment_count>
    <who name="George Staikos">staikos</who>
    <bug_when>2009-08-06 09:45:03 -0700</bug_when>
    <thetext>reopening</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>137867</commentid>
    <comment_count>17</comment_count>
      <attachid>34270</attachid>
    <who name="Steve Block">steveblock</who>
    <bug_when>2009-08-07 07:18:48 -0700</bug_when>
    <thetext>Created attachment 34270
Patch 2 for bug 26993

Fixes bug where callbacks are called twice when permissions are granted synchronously.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>138048</commentid>
    <comment_count>18</comment_count>
      <attachid>34270</attachid>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2009-08-07 12:39:14 -0700</bug_when>
    <thetext>Comment on attachment 34270
Patch 2 for bug 26993

Why do we now have an unused argument?  Seems we should at least be asserting, no?

Why shoudn&apos;t makeSuccessCallbacks take an service parameter?

r- for the unexplained unused argument.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>138067</commentid>
    <comment_count>19</comment_count>
    <who name="Steve Block">steveblock</who>
    <bug_when>2009-08-07 12:59:37 -0700</bug_when>
    <thetext>&gt; Why do we now have an unused argument?
The service argument passed to geolocationServicePositionChanged() should always be equal to m_service.

&gt; Seems we should at least be asserting, no?
Ideally, yes, we&apos;d ASSERT(service == m_service). However, since service is not used in this method (nor is m_service), using service in an ASSERT only gives an &apos;unused argument&apos; build warning in opt builds.

I could ifdef the service argument in the method definition for debug builds only?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>138069</commentid>
    <comment_count>20</comment_count>
    <who name="Darin Adler">darin</who>
    <bug_when>2009-08-07 13:00:36 -0700</bug_when>
    <thetext>(In reply to comment #19)
&gt; &gt; Seems we should at least be asserting, no?
&gt; Ideally, yes, we&apos;d ASSERT(service == m_service). However, since service is not
&gt; used in this method (nor is m_service), using service in an ASSERT only gives
&gt; an &apos;unused argument&apos; build warning in opt builds.

The ASSERT_UNUSED macro is for this sort of situation.

    ASSERT_UNUSED(service, service == m_service);

The above will do the trick.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>138115</commentid>
    <comment_count>21</comment_count>
    <who name="George Staikos">staikos</who>
    <bug_when>2009-08-07 13:45:16 -0700</bug_when>
    <thetext>*** Bug 27690 has been marked as a duplicate of this bug. ***</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>138121</commentid>
    <comment_count>22</comment_count>
      <attachid>34323</attachid>
    <who name="Steve Block">steveblock</who>
    <bug_when>2009-08-07 13:48:48 -0700</bug_when>
    <thetext>Created attachment 34323
Patch 3 for bug 26993

Updated to use ASSERT_UNUSED.

Thanks - I wasn&apos;t aware of that macro.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>139435</commentid>
    <comment_count>23</comment_count>
      <attachid>34323</attachid>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2009-08-12 11:13:51 -0700</bug_when>
    <thetext>Comment on attachment 34323
Patch 3 for bug 26993

Your ChangeLog shoudl have said &quot;No new tests possible.&apos; and explained why.  Tests are always required! :)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>139574</commentid>
    <comment_count>24</comment_count>
      <attachid>34323</attachid>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2009-08-12 15:06:32 -0700</bug_when>
    <thetext>Comment on attachment 34323
Patch 3 for bug 26993

Rejecting patch 34323 from commit-queue.  This patch will require manual commit.

Failed to run &quot;[&apos;git&apos;, &apos;svn&apos;, &apos;dcommit&apos;]&quot;  exit_code: 1  cwd: None</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>139576</commentid>
    <comment_count>25</comment_count>
      <attachid>34323</attachid>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2009-08-12 15:08:09 -0700</bug_when>
    <thetext>Comment on attachment 34323
Patch 3 for bug 26993

Tests passed.  ChangeLog was out of date by the time it went to commit.  Will land manually.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>139579</commentid>
    <comment_count>26</comment_count>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2009-08-12 15:09:02 -0700</bug_when>
    <thetext>Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	WebCore/ChangeLog
	M	WebCore/page/Geolocation.cpp
	M	WebCore/page/Geolocation.h
Committed r47152
	M	WebCore/ChangeLog
	M	WebCore/page/Geolocation.cpp
	M	WebCore/page/Geolocation.h
r47152 = 27684299a4c6bc752037f37c7391cb19a17e7c60 (trunk)
No changes between current HEAD and refs/remotes/trunk
Resetting to the latest refs/remotes/trunk
http://trac.webkit.org/changeset/47152</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>139669</commentid>
    <comment_count>27</comment_count>
      <attachid>34323</attachid>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2009-08-12 17:14:35 -0700</bug_when>
    <thetext>Comment on attachment 34323
Patch 3 for bug 26993

Rejecting patch 34323 from commit-queue.  This patch will require manual commit.

Patch https://bugs.webkit.org/attachment.cgi?id=34323 from bug 26993 failed to download and apply.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>33659</attachid>
            <date>2009-07-28 12:10:38 -0700</date>
            <delta_ts>2009-07-31 23:43:28 -0700</delta_ts>
            <desc>the patch</desc>
            <filename>26993.patch</filename>
            <type>text/plain</type>
            <size>1371</size>
            <attacher name="Yong Li">yong.li.webkit</attacher>
            
              <data encoding="base64">ZGlmZiAtLWdpdCBhL1dlYkNvcmUvQ2hhbmdlTG9nIGIvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXgg
YTZjZGNlZC4uNTQ1NGU2MCAxMDA2NDQKLS0tIGEvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvV2Vi
Q29yZS9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxMyBAQAorMjAwOS0wNy0yOCAgWW9uZyBMaSAgPHlv
bmcubGlAdG9yY2htb2JpbGUuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09Q
UyEpLgorCisgICAgICAgIEZpeCBHZW9sb2NhdGlvbiBwZXJtaXNzaW9uIHByb2JsZW0KKyAgICAg
ICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTI2OTkzCisKKyAgICAg
ICAgKiBwYWdlL0dlb2xvY2F0aW9uLmNwcDoKKyAgICAgICAgKFdlYkNvcmU6Okdlb2xvY2F0aW9u
OjpyZXF1ZXN0UGVybWlzc2lvbik6CisKIDIwMDktMDctMjggIFhhbiBMb3BleiAgPHhsb3BlekBp
Z2FsaWEuY29tPgogCiAgICAgICAgIFJldmlld2VkIGJ5IEd1c3Rhdm8gTm9yb25oYS4KZGlmZiAt
LWdpdCBhL1dlYkNvcmUvcGFnZS9HZW9sb2NhdGlvbi5jcHAgYi9XZWJDb3JlL3BhZ2UvR2VvbG9j
YXRpb24uY3BwCmluZGV4IDhhYmU4YTYuLjQ2OTg5N2MgMTAwNjQ0Ci0tLSBhL1dlYkNvcmUvcGFn
ZS9HZW9sb2NhdGlvbi5jcHAKKysrIGIvV2ViQ29yZS9wYWdlL0dlb2xvY2F0aW9uLmNwcApAQCAt
MSw1ICsxLDYgQEAKIC8qCiAgKiBDb3B5cmlnaHQgKEMpIDIwMDgsIDIwMDkgQXBwbGUgSW5jLiBB
bGwgUmlnaHRzIFJlc2VydmVkLgorICogQ29weXJpZ2h0IChDKSAyMDA5IFRvcmNoIE1vYmlsZSwg
SW5jLgogICoKICAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkg
Zm9ybXMsIHdpdGggb3Igd2l0aG91dAogICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHBy
b3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCkBAIC0yNjQsMTAgKzI2NSwxMCBA
QCB2b2lkIEdlb2xvY2F0aW9uOjpyZXF1ZXN0UGVybWlzc2lvbigpCiAgICAgaWYgKCFwYWdlKQog
ICAgICAgICByZXR1cm47CiAgICAgCisgICAgbV9hbGxvd0dlb2xvY2F0aW9uID0gSW5Qcm9ncmVz
czsKKwogICAgIC8vIEFzayB0aGUgY2hyb21lOiBpdCBtYWludGFpbnMgdGhlIGdlb2xvY2F0aW9u
IGNoYWxsZW5nZSBwb2xpY3kgaXRzZWxmLgogICAgIHBhZ2UtPmNocm9tZSgpLT5yZXF1ZXN0R2Vv
bG9jYXRpb25QZXJtaXNzaW9uRm9yRnJhbWUobV9mcmFtZSwgdGhpcyk7Ci0gICAgCi0gICAgbV9h
bGxvd0dlb2xvY2F0aW9uID0gSW5Qcm9ncmVzczsKIH0KIAogdm9pZCBHZW9sb2NhdGlvbjo6Z2Vv
bG9jYXRpb25TZXJ2aWNlUG9zaXRpb25DaGFuZ2VkKEdlb2xvY2F0aW9uU2VydmljZSogc2Vydmlj
ZSkK
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>34270</attachid>
            <date>2009-08-07 07:18:48 -0700</date>
            <delta_ts>2009-08-07 12:39:13 -0700</delta_ts>
            <desc>Patch 2 for bug 26993</desc>
            <filename>fixSynchronousPermissions.txt</filename>
            <type>text/plain</type>
            <size>3435</size>
            <attacher name="Steve Block">steveblock</attacher>
            
              <data encoding="base64">SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n
CShyZXZpc2lvbiA0Njg5MCkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA
IC0xLDMgKzEsMjIgQEAKKzIwMDktMDgtMDcgIFN0ZXZlIEJsb2NrICA8c3RldmVibG9ja0Bnb29n
bGUuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg
IEJ1ZyAyNjk5MyA6IEdlb2xvY2F0aW9uOjpyZXF1ZXN0UGVybWlzc2lvbigpCisgICAgICAgIGh0
dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yNjk5MworCisgICAgICAgIFNl
Y29uZCBwYXRjaCB0byBhbGxvdyB0aGUgR2VvbG9jYXRpb24gcGVybWlzc2lvbiByZXF1ZXN0IHRv
IGNocm9tZSB0byBiZSBhc3luY2hyb25vdXMKKyAgICAgICAgb3Igc3luY2hyb25vdXMuIEZpeGVz
IGEgYnVnIHdoZXJlIGNhbGxiYWNrcyB3ZXJlIGNhbGxlZCB0d2ljZSB3aGVuIHBlcm1pc3Npb25z
CisgICAgICAgIGFyZSBncmFudGVkIHN5bmNocm9ub3VzbHkuCisKKyAgICAgICAgTm8gbmV3IHRl
c3RzIHJlcXVpcmVkLgorCisgICAgICAgICogcGFnZS9HZW9sb2NhdGlvbi5jcHA6CisgICAgICAg
IChXZWJDb3JlOjpHZW9sb2NhdGlvbjo6c2V0SXNBbGxvd2VkKTogTW9kaWZpZWQuIENhbGxzIG1h
a2VTdWNjZXNzQ2FsbGJhY2tzKCkgcmF0aGVyIHRoYW4gZ2VvbG9jYXRpb25TZXJ2aWNlUG9zaXRp
b25DaGFuZ2VkKCkuCisgICAgICAgIChXZWJDb3JlOjpHZW9sb2NhdGlvbjo6Z2VvbG9jYXRpb25T
ZXJ2aWNlUG9zaXRpb25DaGFuZ2VkKTogTW9kaWZpZWQuIFVwZGF0ZWQgbG9naWMgdG8gYXZvaWQg
cmVwZWF0ZWQgY2FsbGJhY2tzIHdoZW4gcGVybWlzc2lvbnMgYXJlIGdyYW50ZWQgc3luY2hyb25v
dXNseS4KKyAgICAgICAgKFdlYkNvcmU6Okdlb2xvY2F0aW9uOjptYWtlU3VjY2Vzc0NhbGxiYWNr
cyk6IEFkZGVkLiBDYWxscyBzdWNjZXNzIGNhbGxiYWNrcy4KKyAgICAgICAgKiBwYWdlL0dlb2xv
Y2F0aW9uLmg6IE1vZGlmaWVkLiBBZGRzIG1ha2VTdWNjZXNzQ2FsbGJhY2tzKCkuCisKIDIwMDkt
MDgtMDcgIFNpbW9uIEhhdXNtYW5uICA8c2ltb24uaGF1c21hbm5Abm9raWEuY29tPgogCiAgICAg
ICAgIFJldmlld2VkIGJ5IFRvciBBcm5lIFZlc3Riw7guCkluZGV4OiBXZWJDb3JlL3BhZ2UvR2Vv
bG9jYXRpb24uY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvcGFnZS9HZW9sb2NhdGlvbi5jcHAJ
KHJldmlzaW9uIDQ2ODkwKQorKysgV2ViQ29yZS9wYWdlL0dlb2xvY2F0aW9uLmNwcAkod29ya2lu
ZyBjb3B5KQpAQCAtMTM5LDcgKzEzOSw3IEBAIHZvaWQgR2VvbG9jYXRpb246OnNldElzQWxsb3dl
ZChib29sIGFsbG8KICAgICAKICAgICBpZiAoaXNBbGxvd2VkKCkpIHsKICAgICAgICAgc3RhcnRU
aW1lcnMoKTsKLSAgICAgICAgZ2VvbG9jYXRpb25TZXJ2aWNlUG9zaXRpb25DaGFuZ2VkKG1fc2Vy
dmljZS5nZXQoKSk7CisgICAgICAgIG1ha2VTdWNjZXNzQ2FsbGJhY2tzKCk7CiAgICAgfSBlbHNl
IHsKICAgICAgICAgV1RGOjpSZWZQdHI8V2ViQ29yZTo6UG9zaXRpb25FcnJvcj4gZXJyb3IgPSBX
ZWJDb3JlOjpQb3NpdGlvbkVycm9yOjpjcmVhdGUoUG9zaXRpb25FcnJvcjo6UEVSTUlTU0lPTl9E
RU5JRUQsICJVc2VyIGRpc2FsbG93ZWQgR2VvTG9jYXRpb24iKTsKICAgICAgICAgaGFuZGxlRXJy
b3IoZXJyb3IuZ2V0KCkpOwpAQCAtMjY4LDE2ICsyNjgsMjkgQEAgdm9pZCBHZW9sb2NhdGlvbjo6
cmVxdWVzdFBlcm1pc3Npb24oKQogICAgIHBhZ2UtPmNocm9tZSgpLT5yZXF1ZXN0R2VvbG9jYXRp
b25QZXJtaXNzaW9uRm9yRnJhbWUobV9mcmFtZSwgdGhpcyk7CiB9CiAKLXZvaWQgR2VvbG9jYXRp
b246Omdlb2xvY2F0aW9uU2VydmljZVBvc2l0aW9uQ2hhbmdlZChHZW9sb2NhdGlvblNlcnZpY2Uq
IHNlcnZpY2UpCit2b2lkIEdlb2xvY2F0aW9uOjpnZW9sb2NhdGlvblNlcnZpY2VQb3NpdGlvbkNo
YW5nZWQoR2VvbG9jYXRpb25TZXJ2aWNlKikKIHsKLSAgICBBU1NFUlQoc2VydmljZS0+bGFzdFBv
c2l0aW9uKCkpOworICAgIEFTU0VSVChtX3NlcnZpY2UtPmxhc3RQb3NpdGlvbigpKTsKICAgICAK
LSAgICByZXF1ZXN0UGVybWlzc2lvbigpOwotICAgIGlmICghaXNBbGxvd2VkKCkpCisgICAgaWYg
KCFpc0FsbG93ZWQoKSkgeworICAgICAgICAvLyByZXF1ZXN0UGVybWlzc2lvbigpIHdpbGwgYXNr
IHRoZSBjaHJvbWUgZm9yIHBlcm1pc3Npb24uIFRoaXMgbWF5IGJlCisgICAgICAgIC8vIGltcGxl
bWVudGVkIHN5bmNocm9ub3VzbHkgb3IgYXN5bmNocm9ub3VzbHkuIEluIGJvdGggY2FzZXMsCisg
ICAgICAgIC8vIG1ha2VTdWNjZXNzQ2FsbGJhY2tzKCkgd2lsbCBiZSBjYWxsZWQgaWYgcGVybWlz
c2lvbiBpcyBncmFudGVkLCBzbworICAgICAgICAvLyB0aGVyZSdzIG5vdGhpbmcgbW9yZSB0byBk
byBoZXJlLgorICAgICAgICByZXF1ZXN0UGVybWlzc2lvbigpOwogICAgICAgICByZXR1cm47Cisg
ICAgfQorCisgICAgbWFrZVN1Y2Nlc3NDYWxsYmFja3MoKTsKK30KKwordm9pZCBHZW9sb2NhdGlv
bjo6bWFrZVN1Y2Nlc3NDYWxsYmFja3MoKQoreworICAgIEFTU0VSVChtX3NlcnZpY2UtPmxhc3RQ
b3NpdGlvbigpKTsKKyAgICBBU1NFUlQoaXNBbGxvd2VkKCkpOwogICAgIAotICAgIHNlbmRQb3Np
dGlvblRvT25lU2hvdHMoc2VydmljZS0+bGFzdFBvc2l0aW9uKCkpOwotICAgIHNlbmRQb3NpdGlv
blRvV2F0Y2hlcnMoc2VydmljZS0+bGFzdFBvc2l0aW9uKCkpOworICAgIHNlbmRQb3NpdGlvblRv
T25lU2hvdHMobV9zZXJ2aWNlLT5sYXN0UG9zaXRpb24oKSk7CisgICAgc2VuZFBvc2l0aW9uVG9X
YXRjaGVycyhtX3NlcnZpY2UtPmxhc3RQb3NpdGlvbigpKTsKICAgICAgICAgCiAgICAgbV9vbmVT
aG90cy5jbGVhcigpOwogCkluZGV4OiBXZWJDb3JlL3BhZ2UvR2VvbG9jYXRpb24uaAo9PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09Ci0tLSBXZWJDb3JlL3BhZ2UvR2VvbG9jYXRpb24uaAkocmV2aXNpb24gNDY4OTApCisrKyBX
ZWJDb3JlL3BhZ2UvR2VvbG9jYXRpb24uaAkod29ya2luZyBjb3B5KQpAQCAtMTAyLDYgKzEwMiw3
IEBAIHByaXZhdGU6CiAgICAgdm9pZCBzdGFydFRpbWVyc0ZvcldhdGNoZXJzKCk7CiAgICAgdm9p
ZCBzdGFydFRpbWVycygpOwogICAgIAorICAgIHZvaWQgbWFrZVN1Y2Nlc3NDYWxsYmFja3MoKTsK
ICAgICB2b2lkIGhhbmRsZUVycm9yKFBvc2l0aW9uRXJyb3IqKTsKIAogICAgIHZvaWQgcmVxdWVz
dFBlcm1pc3Npb24oKTsK
</data>
<flag name="review"
          id="18436"
          type_id="1"
          status="-"
          setter="eric"
    />
          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>34323</attachid>
            <date>2009-08-07 13:48:48 -0700</date>
            <delta_ts>2009-08-12 17:14:35 -0700</delta_ts>
            <desc>Patch 3 for bug 26993</desc>
            <filename>fixSynchronousPermissions2.txt</filename>
            <type>text/plain</type>
            <size>3324</size>
            <attacher name="Steve Block">steveblock</attacher>
            
              <data encoding="base64">SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n
CShyZXZpc2lvbiA0NjkwOSkKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA
IC0xLDMgKzEsMjIgQEAKKzIwMDktMDgtMDcgIFN0ZXZlIEJsb2NrICA8c3RldmVibG9ja0Bnb29n
bGUuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg
IEJ1ZyAyNjk5MyA6IEdlb2xvY2F0aW9uOjpyZXF1ZXN0UGVybWlzc2lvbigpCisgICAgICAgIGh0
dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yNjk5MworCisgICAgICAgIFNl
Y29uZCBwYXRjaCB0byBhbGxvdyB0aGUgR2VvbG9jYXRpb24gcGVybWlzc2lvbiByZXF1ZXN0IHRv
IGNocm9tZSB0byBiZSBhc3luY2hyb25vdXMKKyAgICAgICAgb3Igc3luY2hyb25vdXMuIEZpeGVz
IGEgYnVnIHdoZXJlIGNhbGxiYWNrcyB3ZXJlIGNhbGxlZCB0d2ljZSB3aGVuIHBlcm1pc3Npb25z
CisgICAgICAgIGFyZSBncmFudGVkIHN5bmNocm9ub3VzbHkuCisKKyAgICAgICAgTm8gbmV3IHRl
c3RzIHJlcXVpcmVkLgorCisgICAgICAgICogcGFnZS9HZW9sb2NhdGlvbi5jcHA6CisgICAgICAg
IChXZWJDb3JlOjpHZW9sb2NhdGlvbjo6c2V0SXNBbGxvd2VkKTogTW9kaWZpZWQuIENhbGxzIG1h
a2VTdWNjZXNzQ2FsbGJhY2tzKCkgcmF0aGVyIHRoYW4gZ2VvbG9jYXRpb25TZXJ2aWNlUG9zaXRp
b25DaGFuZ2VkKCkuCisgICAgICAgIChXZWJDb3JlOjpHZW9sb2NhdGlvbjo6Z2VvbG9jYXRpb25T
ZXJ2aWNlUG9zaXRpb25DaGFuZ2VkKTogTW9kaWZpZWQuIFVwZGF0ZWQgbG9naWMgdG8gYXZvaWQg
cmVwZWF0ZWQgY2FsbGJhY2tzIHdoZW4gcGVybWlzc2lvbnMgYXJlIGdyYW50ZWQgc3luY2hyb25v
dXNseS4KKyAgICAgICAgKFdlYkNvcmU6Okdlb2xvY2F0aW9uOjptYWtlU3VjY2Vzc0NhbGxiYWNr
cyk6IEFkZGVkLiBDYWxscyBzdWNjZXNzIGNhbGxiYWNrcy4KKyAgICAgICAgKiBwYWdlL0dlb2xv
Y2F0aW9uLmg6IE1vZGlmaWVkLiBBZGRzIG1ha2VTdWNjZXNzQ2FsbGJhY2tzKCkuCisKIDIwMDkt
MDgtMDcgIFN0ZXZlIEJsb2NrICA8c3RldmVibG9ja0Bnb29nbGUuY29tPgogCiAgICAgICAgIFJl
dmlld2VkIGJ5IERhcmluIEFkbGVyLgpJbmRleDogV2ViQ29yZS9wYWdlL0dlb2xvY2F0aW9uLmNw
cAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09Ci0tLSBXZWJDb3JlL3BhZ2UvR2VvbG9jYXRpb24uY3BwCShyZXZpc2lvbiA0
NjkwOSkKKysrIFdlYkNvcmUvcGFnZS9HZW9sb2NhdGlvbi5jcHAJKHdvcmtpbmcgY29weSkKQEAg
LTEzOSw3ICsxMzksNyBAQCB2b2lkIEdlb2xvY2F0aW9uOjpzZXRJc0FsbG93ZWQoYm9vbCBhbGxv
CiAgICAgCiAgICAgaWYgKGlzQWxsb3dlZCgpKSB7CiAgICAgICAgIHN0YXJ0VGltZXJzKCk7Ci0g
ICAgICAgIGdlb2xvY2F0aW9uU2VydmljZVBvc2l0aW9uQ2hhbmdlZChtX3NlcnZpY2UuZ2V0KCkp
OworICAgICAgICBtYWtlU3VjY2Vzc0NhbGxiYWNrcygpOwogICAgIH0gZWxzZSB7CiAgICAgICAg
IFdURjo6UmVmUHRyPFdlYkNvcmU6OlBvc2l0aW9uRXJyb3I+IGVycm9yID0gV2ViQ29yZTo6UG9z
aXRpb25FcnJvcjo6Y3JlYXRlKFBvc2l0aW9uRXJyb3I6OlBFUk1JU1NJT05fREVOSUVELCAiVXNl
ciBkaXNhbGxvd2VkIEdlb0xvY2F0aW9uIik7CiAgICAgICAgIGhhbmRsZUVycm9yKGVycm9yLmdl
dCgpKTsKQEAgLTI3MCwxNCArMjcwLDI4IEBAIHZvaWQgR2VvbG9jYXRpb246OnJlcXVlc3RQZXJt
aXNzaW9uKCkKIAogdm9pZCBHZW9sb2NhdGlvbjo6Z2VvbG9jYXRpb25TZXJ2aWNlUG9zaXRpb25D
aGFuZ2VkKEdlb2xvY2F0aW9uU2VydmljZSogc2VydmljZSkKIHsKLSAgICBBU1NFUlQoc2Vydmlj
ZS0+bGFzdFBvc2l0aW9uKCkpOworICAgIEFTU0VSVF9VTlVTRUQoc2VydmljZSwgc2VydmljZSA9
PSBtX3NlcnZpY2UpOworICAgIEFTU0VSVChtX3NlcnZpY2UtPmxhc3RQb3NpdGlvbigpKTsKICAg
ICAKLSAgICByZXF1ZXN0UGVybWlzc2lvbigpOwotICAgIGlmICghaXNBbGxvd2VkKCkpCisgICAg
aWYgKCFpc0FsbG93ZWQoKSkgeworICAgICAgICAvLyByZXF1ZXN0UGVybWlzc2lvbigpIHdpbGwg
YXNrIHRoZSBjaHJvbWUgZm9yIHBlcm1pc3Npb24uIFRoaXMgbWF5IGJlCisgICAgICAgIC8vIGlt
cGxlbWVudGVkIHN5bmNocm9ub3VzbHkgb3IgYXN5bmNocm9ub3VzbHkuIEluIGJvdGggY2FzZXMs
CisgICAgICAgIC8vIG1ha2VTdWNjZXNzQ2FsbGJhY2tzKCkgd2lsbCBiZSBjYWxsZWQgaWYgcGVy
bWlzc2lvbiBpcyBncmFudGVkLCBzbworICAgICAgICAvLyB0aGVyZSdzIG5vdGhpbmcgbW9yZSB0
byBkbyBoZXJlLgorICAgICAgICByZXF1ZXN0UGVybWlzc2lvbigpOwogICAgICAgICByZXR1cm47
CisgICAgfQorCisgICAgbWFrZVN1Y2Nlc3NDYWxsYmFja3MoKTsKK30KKwordm9pZCBHZW9sb2Nh
dGlvbjo6bWFrZVN1Y2Nlc3NDYWxsYmFja3MoKQoreworICAgIEFTU0VSVChtX3NlcnZpY2UtPmxh
c3RQb3NpdGlvbigpKTsKKyAgICBBU1NFUlQoaXNBbGxvd2VkKCkpOwogICAgIAotICAgIHNlbmRQ
b3NpdGlvblRvT25lU2hvdHMoc2VydmljZS0+bGFzdFBvc2l0aW9uKCkpOwotICAgIHNlbmRQb3Np
dGlvblRvV2F0Y2hlcnMoc2VydmljZS0+bGFzdFBvc2l0aW9uKCkpOworICAgIHNlbmRQb3NpdGlv
blRvT25lU2hvdHMobV9zZXJ2aWNlLT5sYXN0UG9zaXRpb24oKSk7CisgICAgc2VuZFBvc2l0aW9u
VG9XYXRjaGVycyhtX3NlcnZpY2UtPmxhc3RQb3NpdGlvbigpKTsKICAgICAgICAgCiAgICAgbV9v
bmVTaG90cy5jbGVhcigpOwogCkluZGV4OiBXZWJDb3JlL3BhZ2UvR2VvbG9jYXRpb24uaAo9PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09Ci0tLSBXZWJDb3JlL3BhZ2UvR2VvbG9jYXRpb24uaAkocmV2aXNpb24gNDY5MDkpCisr
KyBXZWJDb3JlL3BhZ2UvR2VvbG9jYXRpb24uaAkod29ya2luZyBjb3B5KQpAQCAtMTAyLDYgKzEw
Miw3IEBAIHByaXZhdGU6CiAgICAgdm9pZCBzdGFydFRpbWVyc0ZvcldhdGNoZXJzKCk7CiAgICAg
dm9pZCBzdGFydFRpbWVycygpOwogICAgIAorICAgIHZvaWQgbWFrZVN1Y2Nlc3NDYWxsYmFja3Mo
KTsKICAgICB2b2lkIGhhbmRsZUVycm9yKFBvc2l0aW9uRXJyb3IqKTsKIAogICAgIHZvaWQgcmVx
dWVzdFBlcm1pc3Npb24oKTsK
</data>
<flag name="review"
          id="18497"
          type_id="1"
          status="+"
          setter="eric"
    />
    <flag name="commit-queue"
          id="18837"
          type_id="3"
          status="-"
          setter="eric"
    />
          </attachment>
      

    </bug>

</bugzilla>