<?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>56703</bug_id>
          
          <creation_ts>2011-03-18 20:08:41 -0700</creation_ts>
          <short_desc>window.localStorage should return undefined if LocalStorage is 100% disabled (right now it returns null)</short_desc>
          <delta_ts>2022-09-11 13:37:19 -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>DOM</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>All</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>UNCONFIRMED</bug_status>
          <resolution></resolution>
          
          
          <bug_file_loc>http://dev.w3.org/html5/webstorage/#dom-localstorage</bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>0</everconfirmed>
          <reporter name="Jeff Johnson">opendarwin</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>ap</cc>
    
    <cc>beidson</cc>
    
    <cc>ian</cc>
    
    <cc>jorlow</cc>
    
    <cc>mjs</cc>
    
    <cc>mkwst</cc>
    
    <cc>sihui_liu</cc>
    
    <cc>wilander</cc>
    
    <cc>xqb748</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>370087</commentid>
    <comment_count>0</comment_count>
    <who name="Jeff Johnson">opendarwin</who>
    <bug_when>2011-03-18 20:08:41 -0700</bug_when>
    <thetext>According to http://dev.w3.org/html5/webstorage/#dom-localstorage

    When the localStorage attribute is accessed, the user agent must run the following steps:
    1. The user agent may throw a SECURITY_ERR exception instead of returning a Storage object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to persist data).
    2. If the Document&apos;s origin is not a scheme/host/port tuple, then throw a SECURITY_ERR exception and abort these steps.
    3. Check to see if the user agent has allocated a local storage area for the origin of the Document of the Window object on which the attribute was accessed. If it has not, create a new storage area for that origin.
    4. Return the Storage object associated with that origin&apos;s local storage area. Each Document object must have a separate object for its Window&apos;s localStorage attribute.

Thus, if the user agent disabled localStorage and does not return a localStorage object, it is expected to throw a SECURITY_ERR.

However, DOMWindow::localStorage(ExceptionCode&amp; ec) from Source/WebCore/page/DomWindow.cpp contains this code:

    if (!document-&gt;securityOrigin()-&gt;canAccessLocalStorage()) {
        ec = SECURITY_ERR;
        return 0;
    }

    Page* page = document-&gt;page();
    if (!page)
        return 0;

    if (!page-&gt;settings()-&gt;localStorageEnabled())
        return 0;

When local storage is not enabled, it does not raise SECURITY_ERR, it just returns null.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>472985</commentid>
    <comment_count>1</comment_count>
      <attachid>108628</attachid>
    <who name="Antaryami Pandia">xqb748</who>
    <bug_when>2011-09-26 00:00:07 -0700</bug_when>
    <thetext>Created attachment 108628
Proposed Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>477508</commentid>
    <comment_count>2</comment_count>
    <who name="Antaryami Pandia">xqb748</who>
    <bug_when>2011-10-04 02:35:44 -0700</bug_when>
    <thetext>Hi Jeremy,
Please review the patch.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>493770</commentid>
    <comment_count>3</comment_count>
    <who name="Jeremy Orlow">jorlow</who>
    <bug_when>2011-10-31 23:50:36 -0700</bug_when>
    <thetext>Seems reasonable, but you should write a test.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>493861</commentid>
    <comment_count>4</comment_count>
      <attachid>113162</attachid>
    <who name="Antaryami Pandia">xqb748</who>
    <bug_when>2011-11-01 05:55:45 -0700</bug_when>
    <thetext>Created attachment 113162
Updated patch

Patch with test.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>506686</commentid>
    <comment_count>5</comment_count>
    <who name="Antaryami Pandia">xqb748</who>
    <bug_when>2011-11-20 21:18:35 -0800</bug_when>
    <thetext>Hi Jeremy,Please review the patch.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>513557</commentid>
    <comment_count>6</comment_count>
      <attachid>113162</attachid>
    <who name="Hajime Morrita">morrita</who>
    <bug_when>2011-12-01 23:35:00 -0800</bug_when>
    <thetext>Comment on attachment 113162
Updated patch

Code itself looks nice.
Please use text-based test. you can search dumpAsText() in the existing test cases to see how it works.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>513637</commentid>
    <comment_count>7</comment_count>
      <attachid>117595</attachid>
    <who name="Antaryami Pandia">xqb748</who>
    <bug_when>2011-12-02 02:39:01 -0800</bug_when>
    <thetext>Created attachment 117595
Updated patch

Patch with review comments.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>513824</commentid>
    <comment_count>8</comment_count>
      <attachid>117595</attachid>
    <who name="Darin Adler">darin</who>
    <bug_when>2011-12-02 09:12:10 -0800</bug_when>
    <thetext>Comment on attachment 117595
Updated patch

The current behavior of not throwing is intentional. What’s the rationale for the change?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>513825</commentid>
    <comment_count>9</comment_count>
      <attachid>117595</attachid>
    <who name="Darin Adler">darin</who>
    <bug_when>2011-12-02 09:12:51 -0800</bug_when>
    <thetext>Comment on attachment 117595
Updated patch

I see, it’s a “match the specification” change. I suspect this will cause problems with some websites. Not sure what to do about that.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>513827</commentid>
    <comment_count>10</comment_count>
    <who name="Brady Eidson">beidson</who>
    <bug_when>2011-12-02 09:16:11 -0800</bug_when>
    <thetext>(In reply to comment #9)
&gt; (From update of attachment 117595 [details])
&gt; I see, it’s a “match the specification” change. I suspect this will cause problems with some websites. Not sure what to do about that.

I do not agree that this is a &quot;match the specification&quot; change.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>513850</commentid>
    <comment_count>11</comment_count>
    <who name="Maciej Stachowiak">mjs</who>
    <bug_when>2011-12-02 09:42:40 -0800</bug_when>
    <thetext>I think it&apos;s likely that this change will cause sites that use local storage to be broken in private browsing mode. The intent is probably to let sites gracefully handle the case where they are not allowed to store anything, but in practice many will ignore this case. This will make private browsing a less effective feature.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>513855</commentid>
    <comment_count>12</comment_count>
    <who name="Brady Eidson">beidson</who>
    <bug_when>2011-12-02 09:43:51 -0800</bug_when>
    <thetext>(In reply to comment #10)
&gt; (In reply to comment #9)
&gt; &gt; (From update of attachment 117595 [details] [details])
&gt; &gt; I see, it’s a “match the specification” change. I suspect this will cause problems with some websites. Not sure what to do about that.
&gt; 
&gt; I do not agree that this is a &quot;match the specification&quot; change.

To elaborate:

I agree that the spec suggests that if a user agent supports LocalStorage but LocalStorage is currently disabled, a security exception should be thrown.

WebKit is not a &quot;web browser&quot; engine but rather a &quot;web content rendering* engine.  LocalStorage is something that a user agent can support but many don&apos;t want to support it.

In Safari, for example, the LocalStorage object is always there because Safari nominally supports it.  Even when accessing it might throw an exception such as when private browsing is enabled, or might fail for other reasons such as when the quota has been lowered below the current usage.

But in another WebKit application they might never want LocalStorage to work.  They are a user agent that renders web content but not with LocalStorage support.  LocalStorage isn&apos;t just disabled;  It is meant to not exist at all within that user agent.

There&apos;s many WebKit apps besides browsers.  Many of those have never had LocalStorage support and don&apos;t want it.  This change will break them by causing them to start throwing exceptions where they didn&apos;t in the past.

I think some confusion might be over the naming of &quot;localStorageEnabled()&quot; as a setting.  That suggests this represents some checkbox that a browser user could flip.  We could rename the setting in code to &quot;localStorageSupported()&quot; to alleviate this confusion in the future.

If we want to support this edge case of the spec in WebKit I think we should add a new setting that is explicitly about &quot;LocalStorage is supported in this user agent, but it&apos;s use is currently disallowed.&quot;

===

All of that said...  this is clearly a &quot;may&quot; clause in the spec, not a &quot;has to&quot; clause.  Is there any reason we think this is important?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>513863</commentid>
    <comment_count>13</comment_count>
    <who name="Brady Eidson">beidson</who>
    <bug_when>2011-12-02 09:45:56 -0800</bug_when>
    <thetext>(In reply to comment #12)
&gt; (In reply to comment #10)
&gt; I agree that the spec suggests that if a user agent supports LocalStorage but LocalStorage is currently disabled, a security exception should be thrown.
...
&gt; All of that said...  this is clearly a &quot;may&quot; clause in the spec, not a &quot;has to&quot; clause.  Is there any reason we think this is important?

At the top of my comment, I should have said &quot;spec suggests that if a user agent supports LocalStorage but LocalStorage is currently disabled, a security exception *COULD* be thrown.&quot;

Setting aside my arguments that WebKit is more than just about browsers and Maciejs objections regarding private browsing...  I don&apos;t see why this change is important.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>513993</commentid>
    <comment_count>14</comment_count>
    <who name="Jeff Johnson">opendarwin</who>
    <bug_when>2011-12-02 12:01:18 -0800</bug_when>
    <thetext>As background, if that helps, I discovered the difference with the spec while working on this bug:

https://bugs.webkit.org/show_bug.cgi?id=56354 Web Inspector: empty, non-functional window

Although it&apos;s true that there&apos;s a &quot;may&quot; in step 1, there&apos;s a &quot;must&quot; prefacing the steps, and if you go through all of the steps, it seems as far as I can tell that the only options are to throw an exception or return a local storage object. Returning null doesn&apos;t seem to be a valid option according to the spec.

I should note that in my experience of running Safari with local storage disabled, which I continue to do to this day, the choice is usually not between throwing an exception or having a web site work correctly. The web sites just assume they can use local storage and don&apos;t even check for null, so the choice is between throwing an exception or getting a javascript error.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>514005</commentid>
    <comment_count>15</comment_count>
    <who name="Brady Eidson">beidson</who>
    <bug_when>2011-12-02 12:16:19 -0800</bug_when>
    <thetext>(In reply to comment #14)
&gt; As background, if that helps, I discovered the difference with the spec while working on this bug:
&gt; 
&gt; https://bugs.webkit.org/show_bug.cgi?id=56354 Web Inspector: empty, non-functional window
&gt; 
&gt; Although it&apos;s true that there&apos;s a &quot;may&quot; in step 1, there&apos;s a &quot;must&quot; prefacing the steps, and if you go through all of the steps, it seems as far as I can tell that the only options are to throw an exception or return a local storage object. 

I think you&apos;re referring to &quot;User agents must have a set of local storage areas, one for each origin&quot; and yes - to be a *full* HTML5 compliant user agent it would have to have the local storage areas.

But WebKit is not *only* a 100% HTML5 engine.  It supports plenty of modes where various HTML5 features are missing entirely.  This is one of those modes we need to continue supporting.

&gt;Returning null doesn&apos;t seem to be a valid option according to the spec.

This made me realize that yes, returning null for a missing feature is incorrect behavior.  We should be returning undefined here, which is the appropriate behavior for any user agent and any missing feature.

&gt; I should note that in my experience of running Safari with local storage disabled, which I continue to do to this day, the choice is usually not between throwing an exception or having a web site work correctly. The web sites just assume they can use local storage and don&apos;t even check for null, so the choice is between throwing an exception or getting a javascript error.

How is it you run Safari with LocalStorage disabled?  AFAIK, Safari doesn&apos;t support doing this.  Twiddling the hidden WebKit default yourself gets you in to unsupported power-user land.

And this may be true for web sites where you notice it, but I&apos;m not suggesting there *might be* web content that properly and wisely do feature testing and change their behavior to match.  I&apos;m saying there *is* such content that this change would break.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>514183</commentid>
    <comment_count>16</comment_count>
    <who name="Ian &apos;Hixie&apos; Hickson">ian</who>
    <bug_when>2011-12-02 14:48:40 -0800</bug_when>
    <thetext>Indeed. Note in particular this paragraph from the conformance subsection of the HTML standard:

&quot;When support for a feature is disabled (e.g. as an emergency measure to mitigate a security problem, or to aid in development, or for performance reasons), user agents must act as if they had no support for the feature whatsoever, and as if the feature was not mentioned in this specification. For example, if a particular feature is accessed via an attribute in a Web IDL interface, the attribute itself would be omitted from the objects that implement that interface — leaving the attribute on the object but making it return null or throw an exception is insufficient.&quot;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>514214</commentid>
    <comment_count>17</comment_count>
    <who name="Brady Eidson">beidson</who>
    <bug_when>2011-12-02 15:11:07 -0800</bug_when>
    <thetext>(In reply to comment #16)
&gt; Indeed. Note in particular this paragraph from the conformance subsection of the HTML standard:
&gt; 
&gt; &quot;When support for a feature is disabled (e.g. as an emergency measure to mitigate a security problem, or to aid in development, or for performance reasons), user agents must act as if they had no support for the feature whatsoever, and as if the feature was not mentioned in this specification. For example, if a particular feature is accessed via an attribute in a Web IDL interface, the attribute itself would be omitted from the objects that implement that interface — leaving the attribute on the object but making it return null or throw an exception is insufficient.&quot;

Thanks Hixie!

Retitling this bug to reflect the real problem which is that we return null instead of undefined in this case.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>514215</commentid>
    <comment_count>18</comment_count>
      <attachid>117595</attachid>
    <who name="Brady Eidson">beidson</who>
    <bug_when>2011-12-02 15:11:43 -0800</bug_when>
    <thetext>Comment on attachment 117595
Updated patch

We&apos;ve confirmed this is not the behavior the spec calls for and that it&apos;s not the behavior we want.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>514265</commentid>
    <comment_count>19</comment_count>
    <who name="Jeff Johnson">opendarwin</who>
    <bug_when>2011-12-02 16:16:57 -0800</bug_when>
    <thetext>(In reply to comment #15)
&gt; &gt;Returning null doesn&apos;t seem to be a valid option according to the spec.
&gt; 
&gt; This made me realize that yes, returning null for a missing feature is incorrect behavior.  We should be returning undefined here, which is the appropriate behavior for any user agent and any missing feature.

In light of Hixie&apos;s comment, that sounds fine to me.

&gt; How is it you run Safari with LocalStorage disabled?  AFAIK, Safari doesn&apos;t support doing this.  Twiddling the hidden WebKit default yourself gets you in to unsupported power-user land.

I&apos;m not looking for support. I just noticed a bug and filed it. :-)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>607301</commentid>
    <comment_count>20</comment_count>
      <attachid>117595</attachid>
    <who name="Ryosuke Niwa">rniwa</who>
    <bug_when>2012-04-21 17:58:53 -0700</bug_when>
    <thetext>Comment on attachment 117595
Updated patch

cq- given r-.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>108628</attachid>
            <date>2011-09-26 00:00:07 -0700</date>
            <delta_ts>2011-11-01 05:55:45 -0700</delta_ts>
            <desc>Proposed Patch</desc>
            <filename>56703.txt</filename>
            <type>text/plain</type>
            <size>1392</size>
            <attacher name="Antaryami Pandia">xqb748</attacher>
            
              <data encoding="base64">SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDk1OTM1KQorKysgU291cmNlL1dlYkNvcmUvQ2hhbmdl
TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTUgQEAKKzIwMTEtMDktMjUgIEFudGFyeWFt
aSBQYW5kaWEgIDxhbnRhcnlhbWkucGFuZGlhQG1vdG9yb2xhLmNvbT4KKworICAgICAgICB3aW5k
b3cubG9jYWxTdG9yYWdlIHNob3VsZCB0aHJvdyBTRUNVUklUWV9FUlIgd2hlbiBsb2NhbFN0b3Jh
Z2UgaXMgZGlzYWJsZWQuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVn
LmNnaT9pZD01NjcwMworCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisg
ICAgICAgIE5vIG5ldyB0ZXN0cy4gKE9PUFMhKQorCisgICAgICAgICogcGFnZS9ET01XaW5kb3cu
Y3BwOgorICAgICAgICAoV2ViQ29yZTo6RE9NV2luZG93Ojpsb2NhbFN0b3JhZ2UpOgorCiAyMDEx
LTA5LTI1ICBFdW5taSBMZWUgIDxldW5taTE1LmxlZUBzYW1zdW5nLmNvbT4KIAogICAgICAgICBb
RUZMXSBNb3ZlIEd0a1dpZGdldEJhY2tpbmdTdG9yZUNhaXJvIHRvIHRoZSBjYWlybyBkaXJlY3Rv
cnkgYW5kIG1vZGlmeSB0byB1c2UgaW4gdGhlIEVGTC4KSW5kZXg6IFNvdXJjZS9XZWJDb3JlL3Bh
Z2UvRE9NV2luZG93LmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2ViQ29yZS9wYWdlL0RPTVdp
bmRvdy5jcHAJKHJldmlzaW9uIDk1OTM0KQorKysgU291cmNlL1dlYkNvcmUvcGFnZS9ET01XaW5k
b3cuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC02NzEsOCArNjcxLDEwIEBAIFN0b3JhZ2UqIERPTVdp
bmRvdzo6bG9jYWxTdG9yYWdlKEV4Y2VwdGkKICAgICBpZiAoIXBhZ2UpCiAgICAgICAgIHJldHVy
biAwOwogCi0gICAgaWYgKCFwYWdlLT5zZXR0aW5ncygpLT5sb2NhbFN0b3JhZ2VFbmFibGVkKCkp
CisgICAgaWYgKCFwYWdlLT5zZXR0aW5ncygpLT5sb2NhbFN0b3JhZ2VFbmFibGVkKCkpIHsKKyAg
ICAgICAgZWMgPSBTRUNVUklUWV9FUlI7CiAgICAgICAgIHJldHVybiAwOworICAgIH0KIAogICAg
IFJlZlB0cjxTdG9yYWdlQXJlYT4gc3RvcmFnZUFyZWEgPSBwYWdlLT5ncm91cCgpLmxvY2FsU3Rv
cmFnZSgpLT5zdG9yYWdlQXJlYShkb2N1bWVudC0+c2VjdXJpdHlPcmlnaW4oKSk7CiAgICAgSW5z
cGVjdG9ySW5zdHJ1bWVudGF0aW9uOjpkaWRVc2VET01TdG9yYWdlKHBhZ2UsIHN0b3JhZ2VBcmVh
LmdldCgpLCB0cnVlLCBtX2ZyYW1lKTsK
</data>

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>113162</attachid>
            <date>2011-11-01 05:55:45 -0700</date>
            <delta_ts>2011-12-02 02:39:01 -0800</delta_ts>
            <desc>Updated patch</desc>
            <filename>56703.txt</filename>
            <type>text/plain</type>
            <size>3932</size>
            <attacher name="Antaryami Pandia">xqb748</attacher>
            
              <data encoding="base64">SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDk4OTUyKQorKysgU291cmNlL1dlYkNvcmUvQ2hhbmdl
TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTUgQEAKKzIwMTEtMTEtMDEgIEFudGFyeWFt
aSBQYW5kaWEgIDxhbnRhcnlhbWkucGFuZGlhQG1vdG9yb2xhLmNvbT4KKworICAgICAgICB3aW5k
b3cubG9jYWxTdG9yYWdlIHNob3VsZCB0aHJvdyBTRUNVUklUWV9FUlIgd2hlbiBsb2NhbFN0b3Jh
Z2UgaXMgZGlzYWJsZWQuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVn
LmNnaT9pZD01NjcwMworCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisg
ICAgICAgIFRlc3Q6IHN0b3JhZ2UvZG9tc3RvcmFnZS9sb2NhbHN0b3JhZ2UvY2hlY2stZm9yLWxv
Y2FsLXN0b3JhZ2UuaHRtbAorCisgICAgICAgICogcGFnZS9ET01XaW5kb3cuY3BwOgorICAgICAg
ICAoV2ViQ29yZTo6RE9NV2luZG93Ojpsb2NhbFN0b3JhZ2UpOgorCiAyMDExLTExLTAxICBQYXZl
bCBGZWxkbWFuICA8cGZlbGRtYW5AZ29vZ2xlLmNvbT4KIAogICAgICAgICBXZWIgSW5zcGVjdG9y
OiBkbyBub3Qgc3dpdGNoIHBhbmVscyBvbiBDbWQgKyAtPiAgd2hpbGUgaW4gY29uc29sZS4KSW5k
ZXg6IFNvdXJjZS9XZWJDb3JlL3BhZ2UvRE9NV2luZG93LmNwcAo9PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3Vy
Y2UvV2ViQ29yZS9wYWdlL0RPTVdpbmRvdy5jcHAJKHJldmlzaW9uIDk4OTUwKQorKysgU291cmNl
L1dlYkNvcmUvcGFnZS9ET01XaW5kb3cuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC03MjYsOCArNzI2
LDEwIEBAIFN0b3JhZ2UqIERPTVdpbmRvdzo6bG9jYWxTdG9yYWdlKEV4Y2VwdGkKICAgICBpZiAo
IXBhZ2UpCiAgICAgICAgIHJldHVybiAwOwogCi0gICAgaWYgKCFwYWdlLT5zZXR0aW5ncygpLT5s
b2NhbFN0b3JhZ2VFbmFibGVkKCkpCisgICAgaWYgKCFwYWdlLT5zZXR0aW5ncygpLT5sb2NhbFN0
b3JhZ2VFbmFibGVkKCkpIHsKKyAgICAgICAgZWMgPSBTRUNVUklUWV9FUlI7CiAgICAgICAgIHJl
dHVybiAwOworICAgIH0KIAogICAgIFJlZlB0cjxTdG9yYWdlQXJlYT4gc3RvcmFnZUFyZWEgPSBw
YWdlLT5ncm91cCgpLmxvY2FsU3RvcmFnZSgpLT5zdG9yYWdlQXJlYShkb2N1bWVudC0+c2VjdXJp
dHlPcmlnaW4oKSk7CiAgICAgSW5zcGVjdG9ySW5zdHJ1bWVudGF0aW9uOjpkaWRVc2VET01TdG9y
YWdlKHBhZ2UsIHN0b3JhZ2VBcmVhLmdldCgpLCB0cnVlLCBtX2ZyYW1lKTsKSW5kZXg6IExheW91
dFRlc3RzL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlvdXRUZXN0cy9DaGFuZ2VMb2cJKHJl
dmlzaW9uIDk4OTUyKQorKysgTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA
IC0xLDMgKzEsMTMgQEAKKzIwMTEtMTEtMDEgIEFudGFyeWFtaSBQYW5kaWEgIDxhbnRhcnlhbWku
cGFuZGlhQG1vdG9yb2xhLmNvbT4KKworICAgICAgICB3aW5kb3cubG9jYWxTdG9yYWdlIHNob3Vs
ZCB0aHJvdyBTRUNVUklUWV9FUlIgd2hlbiBsb2NhbFN0b3JhZ2UgaXMgZGlzYWJsZWQuCisgICAg
ICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD01NjcwMworCisgICAg
ICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogc3RvcmFnZS9kb21z
dG9yYWdlL2xvY2Fsc3RvcmFnZS9jaGVjay1mb3ItbG9jYWwtc3RvcmFnZS1leHBlY3RlZC50eHQ6
IEFkZGVkLgorICAgICAgICAqIHN0b3JhZ2UvZG9tc3RvcmFnZS9sb2NhbHN0b3JhZ2UvY2hlY2st
Zm9yLWxvY2FsLXN0b3JhZ2UuaHRtbDogQWRkZWQuCisKIDIwMTEtMTEtMDEgIEFuZHJleSBLb3N5
YWtvdiAgPGNhc2VxQGNocm9taXVtLm9yZz4KIAogICAgICAgICBVbnJldmlld2VkIGV4cGVjdGF0
aW9ucyB1cGRhdGUuCkluZGV4OiBMYXlvdXRUZXN0cy9zdG9yYWdlL2RvbXN0b3JhZ2UvbG9jYWxz
dG9yYWdlL2NoZWNrLWZvci1sb2NhbC1zdG9yYWdlLWV4cGVjdGVkLnR4dAo9PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t
LSBMYXlvdXRUZXN0cy9zdG9yYWdlL2RvbXN0b3JhZ2UvbG9jYWxzdG9yYWdlL2NoZWNrLWZvci1s
b2NhbC1zdG9yYWdlLWV4cGVjdGVkLnR4dAkocmV2aXNpb24gMCkKKysrIExheW91dFRlc3RzL3N0
b3JhZ2UvZG9tc3RvcmFnZS9sb2NhbHN0b3JhZ2UvY2hlY2stZm9yLWxvY2FsLXN0b3JhZ2UtZXhw
ZWN0ZWQudHh0CShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDEzIEBACitsYXllciBhdCAoMCwwKSBz
aXplIDgwMHg2MDAKKyAgUmVuZGVyVmlldyBhdCAoMCwwKSBzaXplIDgwMHg2MDAKK2xheWVyIGF0
ICgwLDApIHNpemUgODAweDYwMAorICBSZW5kZXJCbG9jayB7SFRNTH0gYXQgKDAsMCkgc2l6ZSA4
MDB4NjAwCisgICAgUmVuZGVyQm9keSB7Qk9EWX0gYXQgKDgsOCkgc2l6ZSA3ODR4NTg0CisgICAg
ICBSZW5kZXJCbG9jayAoYW5vbnltb3VzKSBhdCAoMCwwKSBzaXplIDc4NHgxOQorICAgICAgICBS
ZW5kZXJUZXh0IHsjdGV4dH0gYXQgKDAsMCkgc2l6ZSAzNTl4MTkKKyAgICAgICAgICB0ZXh0IHJ1
biBhdCAoMCwwKSB3aWR0aCAzNTk6ICJUaGlzIHRlc3RzIHRoYXQgaWYgbG9jYWwgc3RvcmFnZSBp
cyBkaXNhYmxlZCwgaXQgc2hvdWxkIHRocm93LiIKKyAgICAgICAgUmVuZGVyQlIge0JSfSBhdCAo
MzU5LDE1KSBzaXplIDB4MAorICAgICAgUmVuZGVyQmxvY2sge0RJVn0gYXQgKDAsMTkpIHNpemUg
Nzg0eDE5CisgICAgICAgIFJlbmRlclRleHQgeyN0ZXh0fSBhdCAoMCwwKSBzaXplIDEzOHgxOQor
ICAgICAgICAgIHRleHQgcnVuIGF0ICgwLDApIHdpZHRoIDEzODogIkxvY2FsIHN0b3JhZ2UgZW5h
YmxlZCIKKyAgICAgICAgUmVuZGVyQlIge0JSfSBhdCAoMTM4LDE1KSBzaXplIDB4MApJbmRleDog
TGF5b3V0VGVzdHMvc3RvcmFnZS9kb21zdG9yYWdlL2xvY2Fsc3RvcmFnZS9jaGVjay1mb3ItbG9j
YWwtc3RvcmFnZS5odG1sCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL3N0b3JhZ2UvZG9tc3Rv
cmFnZS9sb2NhbHN0b3JhZ2UvY2hlY2stZm9yLWxvY2FsLXN0b3JhZ2UuaHRtbAkocmV2aXNpb24g
MCkKKysrIExheW91dFRlc3RzL3N0b3JhZ2UvZG9tc3RvcmFnZS9sb2NhbHN0b3JhZ2UvY2hlY2st
Zm9yLWxvY2FsLXN0b3JhZ2UuaHRtbAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwyNiBAQAorPGh0
bWw+Cis8aGVhZD4KKzxzY3JpcHQ+CisKK2Z1bmN0aW9uIGxvZyhhKQoreworICAgIGRvY3VtZW50
LmdldEVsZW1lbnRCeUlkKCJsb2dnZXIiKS5pbm5lckhUTUwgKz0gYSArICI8YnI+IjsKK30KKwor
ZnVuY3Rpb24gcnVuVGVzdCgpCit7CisgICAgdHJ5IHsKKyAgICAgICAgaWYgKHdpbmRvdy5sb2Nh
bFN0b3JhZ2UpCisgICAgICAgICAgICBsb2coIkxvY2FsIHN0b3JhZ2UgZW5hYmxlZCIpOworICAg
IH0gY2F0Y2goZSkgeworICAgICAgICBsb2coIkNhdWdodCBleGNlcHRpb24gOiAiICsgZSk7Cisg
ICAgfQorfQorCis8L3NjcmlwdD4KKzwvaGVhZD4KKzxib2R5IG9ubG9hZD0icnVuVGVzdCgpOyI+
CitUaGlzIHRlc3RzIHRoYXQgaWYgbG9jYWwgc3RvcmFnZSBpcyBkaXNhYmxlZCwgaXQgc2hvdWxk
IHRocm93Ljxicj4KKzxkaXYgaWQ9ImxvZ2dlciI+PC9kaXY+Cis8L2JvZHk+Cis8L2h0bWw+IAo=
</data>
<flag name="review"
          id="111425"
          type_id="1"
          status="-"
          setter="morrita"
    />
          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>117595</attachid>
            <date>2011-12-02 02:39:01 -0800</date>
            <delta_ts>2012-04-21 17:58:53 -0700</delta_ts>
            <desc>Updated patch</desc>
            <filename>56703-updated.txt</filename>
            <type>text/plain</type>
            <size>3574</size>
            <attacher name="Antaryami Pandia">xqb748</attacher>
            
              <data encoding="base64">SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDEwMTc3MCkKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n
ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE1IEBACisyMDExLTEyLTAyICBBbnRhcnlh
bWkgUGFuZGlhICA8YW50YXJ5YW1pLnBhbmRpYUBtb3Rvcm9sYS5jb20+CisKKyAgICAgICAgd2lu
ZG93LmxvY2FsU3RvcmFnZSBzaG91bGQgdGhyb3cgU0VDVVJJVFlfRVJSIHdoZW4gbG9jYWxTdG9y
YWdlIGlzIGRpc2FibGVkLgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1
Zy5jZ2k/aWQ9NTY3MDMKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKwor
ICAgICAgICBUZXN0OiBzdG9yYWdlL2RvbXN0b3JhZ2UvbG9jYWxzdG9yYWdlL2NoZWNrLWZvci1s
b2NhbC1zdG9yYWdlLmh0bWwKKworICAgICAgICAqIHBhZ2UvRE9NV2luZG93LmNwcDoKKyAgICAg
ICAgKFdlYkNvcmU6OkRPTVdpbmRvdzo6bG9jYWxTdG9yYWdlKToKKwogMjAxMS0xMi0wMSAgQW5k
cmV5IEtvc3lha292ICA8Y2FzZXFAY2hyb21pdW0ub3JnPgogCiAgICAgICAgIFdlYiBJbnNwZWN0
b3I6IFtFeHRlbnNpb25zIEFQSV0gcGFzcyBwcmVmZXJyZWQgcmVzb3VyY2UgbGluZSBudW1iZXIg
dG8gZXh0ZW5zaW9uJ3Mgb3BlbiByZXNvdXJjZSBoYW5kbGVyCkluZGV4OiBTb3VyY2UvV2ViQ29y
ZS9wYWdlL0RPTVdpbmRvdy5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvcGFnZS9E
T01XaW5kb3cuY3BwCShyZXZpc2lvbiAxMDE3NTkpCisrKyBTb3VyY2UvV2ViQ29yZS9wYWdlL0RP
TVdpbmRvdy5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTcyNyw4ICs3MjcsMTAgQEAgU3RvcmFnZSog
RE9NV2luZG93Ojpsb2NhbFN0b3JhZ2UoRXhjZXB0aQogICAgIGlmICghcGFnZSkKICAgICAgICAg
cmV0dXJuIDA7CiAKLSAgICBpZiAoIXBhZ2UtPnNldHRpbmdzKCktPmxvY2FsU3RvcmFnZUVuYWJs
ZWQoKSkKKyAgICBpZiAoIXBhZ2UtPnNldHRpbmdzKCktPmxvY2FsU3RvcmFnZUVuYWJsZWQoKSkg
eworICAgICAgICBlYyA9IFNFQ1VSSVRZX0VSUjsKICAgICAgICAgcmV0dXJuIDA7CisgICAgfQog
CiAgICAgUmVmUHRyPFN0b3JhZ2VBcmVhPiBzdG9yYWdlQXJlYSA9IHBhZ2UtPmdyb3VwKCkubG9j
YWxTdG9yYWdlKCktPnN0b3JhZ2VBcmVhKGRvY3VtZW50LT5zZWN1cml0eU9yaWdpbigpKTsKICAg
ICBJbnNwZWN0b3JJbnN0cnVtZW50YXRpb246OmRpZFVzZURPTVN0b3JhZ2UocGFnZSwgc3RvcmFn
ZUFyZWEuZ2V0KCksIHRydWUsIG1fZnJhbWUpOwpJbmRleDogTGF5b3V0VGVzdHMvQ2hhbmdlTG9n
Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT0KLS0tIExheW91dFRlc3RzL0NoYW5nZUxvZwkocmV2aXNpb24gMTAxNzcwKQor
KysgTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTMgQEAK
KzIwMTEtMTItMDIgIEFudGFyeWFtaSBQYW5kaWEgIDxhbnRhcnlhbWkucGFuZGlhQG1vdG9yb2xh
LmNvbT4KKworICAgICAgICB3aW5kb3cubG9jYWxTdG9yYWdlIHNob3VsZCB0aHJvdyBTRUNVUklU
WV9FUlIgd2hlbiBsb2NhbFN0b3JhZ2UgaXMgZGlzYWJsZWQuCisgICAgICAgIGh0dHBzOi8vYnVn
cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD01NjcwMworCisgICAgICAgIFJldmlld2VkIGJ5
IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgICogc3RvcmFnZS9kb21zdG9yYWdlL2xvY2Fsc3Rv
cmFnZS9jaGVjay1mb3ItbG9jYWwtc3RvcmFnZS1leHBlY3RlZC50eHQ6IEFkZGVkLgorICAgICAg
ICAqIHN0b3JhZ2UvZG9tc3RvcmFnZS9sb2NhbHN0b3JhZ2UvY2hlY2stZm9yLWxvY2FsLXN0b3Jh
Z2UuaHRtbDogQWRkZWQuCisKIDIwMTEtMTItMDEgIEFuZHJleSBLb3N5YWtvdiAgPGNhc2VxQGNo
cm9taXVtLm9yZz4KIAogICAgICAgICBXZWIgSW5zcGVjdG9yOiBbRXh0ZW5zaW9ucyBBUEldIHBh
c3MgcHJlZmVycmVkIHJlc291cmNlIGxpbmUgbnVtYmVyIHRvIGV4dGVuc2lvbidzIG9wZW4gcmVz
b3VyY2UgaGFuZGxlcgpJbmRleDogTGF5b3V0VGVzdHMvc3RvcmFnZS9kb21zdG9yYWdlL2xvY2Fs
c3RvcmFnZS9jaGVjay1mb3ItbG9jYWwtc3RvcmFnZS1leHBlY3RlZC50eHQKPT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot
LS0gTGF5b3V0VGVzdHMvc3RvcmFnZS9kb21zdG9yYWdlL2xvY2Fsc3RvcmFnZS9jaGVjay1mb3It
bG9jYWwtc3RvcmFnZS1leHBlY3RlZC50eHQJKHJldmlzaW9uIDApCisrKyBMYXlvdXRUZXN0cy9z
dG9yYWdlL2RvbXN0b3JhZ2UvbG9jYWxzdG9yYWdlL2NoZWNrLWZvci1sb2NhbC1zdG9yYWdlLWV4
cGVjdGVkLnR4dAkocmV2aXNpb24gMCkKQEAgLTAsMCArMSwzIEBACitUaGlzIHRlc3RzIHRoYXQg
aWYgbG9jYWwgc3RvcmFnZSBpcyBkaXNhYmxlZCwgaXQgc2hvdWxkIHRocm93LgorTG9jYWwgc3Rv
cmFnZSBlbmFibGVkCisKSW5kZXg6IExheW91dFRlc3RzL3N0b3JhZ2UvZG9tc3RvcmFnZS9sb2Nh
bHN0b3JhZ2UvY2hlY2stZm9yLWxvY2FsLXN0b3JhZ2UuaHRtbAo9PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBMYXlv
dXRUZXN0cy9zdG9yYWdlL2RvbXN0b3JhZ2UvbG9jYWxzdG9yYWdlL2NoZWNrLWZvci1sb2NhbC1z
dG9yYWdlLmh0bWwJKHJldmlzaW9uIDApCisrKyBMYXlvdXRUZXN0cy9zdG9yYWdlL2RvbXN0b3Jh
Z2UvbG9jYWxzdG9yYWdlL2NoZWNrLWZvci1sb2NhbC1zdG9yYWdlLmh0bWwJKHJldmlzaW9uIDAp
CkBAIC0wLDAgKzEsMjkgQEAKKzxodG1sPgorPGhlYWQ+Cis8c2NyaXB0PgorCitpZiAod2luZG93
LmxheW91dFRlc3RDb250cm9sbGVyKQorICAgIGxheW91dFRlc3RDb250cm9sbGVyLmR1bXBBc1Rl
eHQoKTsKKworZnVuY3Rpb24gbG9nKGEpCit7CisgICAgZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQo
ImxvZ2dlciIpLmlubmVySFRNTCArPSBhICsgIjxicj4iOworfQorCitmdW5jdGlvbiBydW5UZXN0
KCkKK3sKKyAgICB0cnkgeworICAgICAgICBpZiAod2luZG93LmxvY2FsU3RvcmFnZSkKKyAgICAg
ICAgICAgIGxvZygiTG9jYWwgc3RvcmFnZSBlbmFibGVkIik7CisgICAgfSBjYXRjaChlKSB7Cisg
ICAgICAgIGxvZygiQ2F1Z2h0IGV4Y2VwdGlvbiA6ICIgKyBlKTsKKyAgICB9Cit9CisKKzwvc2Ny
aXB0PgorPC9oZWFkPgorPGJvZHkgb25sb2FkPSJydW5UZXN0KCk7Ij4KK1RoaXMgdGVzdHMgdGhh
dCBpZiBsb2NhbCBzdG9yYWdlIGlzIGRpc2FibGVkLCBpdCBzaG91bGQgdGhyb3cuPGJyPgorPGRp
diBpZD0ibG9nZ2VyIj48L2Rpdj4KKzwvYm9keT4KKzwvaHRtbD4gCg==
</data>
<flag name="review"
          id="117080"
          type_id="1"
          status="-"
          setter="beidson"
    />
    <flag name="commit-queue"
          id="117081"
          type_id="3"
          status="-"
          setter="rniwa"
    />
          </attachment>
      

    </bug>

</bugzilla>