<?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>49868</bug_id>
          
          <creation_ts>2010-11-20 12:47:57 -0800</creation_ts>
          <short_desc>REGRESSION (r71934): Main search field at Apple tech specs does not accept typing</short_desc>
          <delta_ts>2010-11-29 14:14:53 -0800</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>Mac</rep_platform>
          <op_sys>OS X 10.6</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc>http://support.apple.com/specs/</bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords>InRadar, NeedsReduction, Regression</keywords>
          <priority>P1</priority>
          <bug_severity>Major</bug_severity>
          <target_milestone>---</target_milestone>
          
          <blocked>46015</blocked>
          <everconfirmed>1</everconfirmed>
          <reporter>mitz</reporter>
          <assigned_to name="Dimitri Glazkov (Google)">dglazkov</assigned_to>
          <cc>ap</cc>
    
    <cc>darin</cc>
    
    <cc>dglazkov</cc>
    
    <cc>hyatt</cc>
    
    <cc>pfeldman</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>311969</commentid>
    <comment_count>0</comment_count>
    <who name="">mitz</who>
    <bug_when>2010-11-20 12:47:57 -0800</bug_when>
    <thetext>To reproduce, navigate to the URL, focus the search field next to “Search Tech Specs” and type.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>311970</commentid>
    <comment_count>1</comment_count>
    <who name="">mitz</who>
    <bug_when>2010-11-20 12:49:12 -0800</bug_when>
    <thetext>&lt;rdar://problem/8692047&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>311987</commentid>
    <comment_count>2</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2010-11-20 14:15:00 -0800</bug_when>
    <thetext>The only relevant commit in this range is the shadow DOM-aware event targeting one.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>312008</commentid>
    <comment_count>3</comment_count>
    <who name="Mark Rowe (bdash)">mrowe</who>
    <bug_when>2010-11-20 15:42:12 -0800</bug_when>
    <thetext>Confirmed via bisection that &lt;http://trac.webkit.org/changeset/71934&gt; is to blame.

This also breaks the search field in the web inspector.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>312010</commentid>
    <comment_count>4</comment_count>
    <who name="Dave Hyatt">hyatt</who>
    <bug_when>2010-11-20 16:15:54 -0800</bug_when>
    <thetext>Just a guess, but focus/blur events that remain inside the shadow nodes of the same enclosing explicit element should not retarget.  The same is also true for mouseover and mouseout events that remain inside the object.  If those are now propagating out, that would cause odd behaviors.

See:

http://www.w3.org/TR/xbl/#event2

and then also

sections 6.10 and 6.11.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>312108</commentid>
    <comment_count>5</comment_count>
    <who name="Pavel Feldman">pfeldman</who>
    <bug_when>2010-11-21 07:35:44 -0800</bug_when>
    <thetext>Is anyone looking at this? It does break inspector&apos;s search.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>312361</commentid>
    <comment_count>6</comment_count>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2010-11-22 08:58:03 -0800</bug_when>
    <thetext>Fixing..</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>312829</commentid>
    <comment_count>7</comment_count>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2010-11-23 07:20:11 -0800</bug_when>
    <thetext>(In reply to comment #5)
&gt; Is anyone looking at this? It does break inspector&apos;s search.

FWIW, tech specs behavior is slightly this is different from inspector&apos;s search. You can still search in Inspector by clicking on the loupe.

I&apos;ve been tracking through the code, have some leads.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>312830</commentid>
    <comment_count>8</comment_count>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2010-11-23 07:21:55 -0800</bug_when>
    <thetext>(In reply to comment #4)
&gt; Just a guess, but focus/blur events that remain inside the shadow nodes of the same enclosing explicit element should not retarget.  The same is also true for mouseover and mouseout events that remain inside the object.  If those are now propagating out, that would cause odd behaviors.
&gt; 
&gt; See:
&gt; 
&gt; http://www.w3.org/TR/xbl/#event2
&gt; 
&gt; and then also
&gt; 
&gt; sections 6.10 and 6.11.

Yup, I didn&apos;t yet implement that. However, all of the shadow DOM elements today are explicitly marked as not focusable. I think the issue is with the style recalc not being triggered when focusing somehow. If you go in Inspector and modify width, the problem goes away.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>313529</commentid>
    <comment_count>9</comment_count>
      <attachid>74812</attachid>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2010-11-24 16:50:44 -0800</bug_when>
    <thetext>Created attachment 74812
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>313533</commentid>
    <comment_count>10</comment_count>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2010-11-24 16:52:18 -0800</bug_when>
    <thetext>(In reply to comment #9)
&gt; Created an attachment (id=74812) [details]
&gt; Patch

This corrects the issue with the site reported. The problem still persists with the Inspector, but it&apos;s a totally different issue, related to manipulating (removing, actually) selection while inside of the focus event. I&apos;ll file a separate bug.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>313845</commentid>
    <comment_count>11</comment_count>
    <who name="Pavel Feldman">pfeldman</who>
    <bug_when>2010-11-25 12:55:31 -0800</bug_when>
    <thetext>&gt; This corrects the issue with the site reported. The problem still persists with the Inspector, but it&apos;s a totally different issue, related to manipulating (removing, actually) selection while inside of the focus event. I&apos;ll file a separate bug.

Any idea what regressed it? Is there a bug already?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>313846</commentid>
    <comment_count>12</comment_count>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2010-11-25 13:12:47 -0800</bug_when>
    <thetext>(In reply to comment #11)
&gt; &gt; This corrects the issue with the site reported. The problem still persists with the Inspector, but it&apos;s a totally different issue, related to manipulating (removing, actually) selection while inside of the focus event. I&apos;ll file a separate bug.
&gt; 
&gt; Any idea what regressed it? Is there a bug already?

No yet, I&apos;ll file and provide reduction and fix after the Thanksgiving break. It regressed with the same revision.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>314159</commentid>
    <comment_count>13</comment_count>
      <attachid>74812</attachid>
    <who name="Darin Adler">darin</who>
    <bug_when>2010-11-27 18:26:51 -0800</bug_when>
    <thetext>Comment on attachment 74812
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=74812&amp;action=review

I wonder if some of the code in RenderBlock::hasLineIfEmpty can now be deleted.

&gt; LayoutTests/fast/forms/disabled-search-input.html:59
&gt;  \ No newline at end of file

We normally put those end-of-file newlines in WebKit source files.

&gt; WebCore/rendering/TextControlInnerElements.cpp:54
&gt; +    virtual bool hasLineIfEmpty() const { return true; }

I slightly prefer that such overrides be private rather than public. It’s typically a programming error if someone calls the function on a RenderTextControlInnerBlock* directly, and it’s nice to have this caught at compile time. And the privacy has no effect on overriding.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>314161</commentid>
    <comment_count>14</comment_count>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2010-11-27 18:42:38 -0800</bug_when>
    <thetext>(In reply to comment #13)
&gt; (From update of attachment 74812 [details])
&gt; View in context: https://bugs.webkit.org/attachment.cgi?id=74812&amp;action=review
&gt; 
&gt; I wonder if some of the code in RenderBlock::hasLineIfEmpty can now be deleted.

Not yet. The spin buttons still use it :( But soon, soon, I shall make this all be not so crappy! :)

&gt; 
&gt; &gt; LayoutTests/fast/forms/disabled-search-input.html:59
&gt; &gt;  \ No newline at end of file
&gt; 
&gt; We normally put those end-of-file newlines in WebKit source files.
&gt; 
&gt; &gt; WebCore/rendering/TextControlInnerElements.cpp:54
&gt; &gt; +    virtual bool hasLineIfEmpty() const { return true; }
&gt; 
&gt; I slightly prefer that such overrides be private rather than public. It’s typically a programming error if someone calls the function on a RenderTextControlInnerBlock* directly, and it’s nice to have this caught at compile time. And the privacy has no effect on overriding.

Sounds great! Wil do.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>314164</commentid>
    <comment_count>15</comment_count>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2010-11-27 19:49:08 -0800</bug_when>
    <thetext>(In reply to comment #14)
&gt; (In reply to comment #13)
&gt; &gt; (From update of attachment 74812 [details] [details])
&gt; &gt; View in context: https://bugs.webkit.org/attachment.cgi?id=74812&amp;action=review
&gt; &gt; 
&gt; &gt; I wonder if some of the code in RenderBlock::hasLineIfEmpty can now be deleted.
&gt; 
&gt; Not yet. The spin buttons still use it :( But soon, soon, I shall make this all be not so crappy! :)

I think I can remove one check though. I&apos;ll do that.

&gt; 
&gt; &gt; 
&gt; &gt; &gt; LayoutTests/fast/forms/disabled-search-input.html:59
&gt; &gt; &gt;  \ No newline at end of file
&gt; &gt; 
&gt; &gt; We normally put those end-of-file newlines in WebKit source files.
&gt; &gt; 
&gt; &gt; &gt; WebCore/rendering/TextControlInnerElements.cpp:54
&gt; &gt; &gt; +    virtual bool hasLineIfEmpty() const { return true; }
&gt; &gt; 
&gt; &gt; I slightly prefer that such overrides be private rather than public. It’s typically a programming error if someone calls the function on a RenderTextControlInnerBlock* directly, and it’s nice to have this caught at compile time. And the privacy has no effect on overriding.
&gt; 
&gt; Sounds great! Wil do.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>314474</commentid>
    <comment_count>16</comment_count>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2010-11-29 09:52:31 -0800</bug_when>
    <thetext>Committed r72807: &lt;http://trac.webkit.org/changeset/72807&gt;</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>74812</attachid>
            <date>2010-11-24 16:50:44 -0800</date>
            <delta_ts>2010-11-27 18:26:51 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>bug-49868-20101124165043.patch</filename>
            <type>text/plain</type>
            <size>4293</size>
            <attacher name="Dimitri Glazkov (Google)">dglazkov</attacher>
            
              <data encoding="base64">ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv
ZwppbmRleCBjYWYyNDc3YjQzNWE5ZWNmZjcyYzJjOTY3M2Q5MDJiZjEyMGQzYTc1Li4zZDI4OWJj
ZTZkNjZkMGI5ZDUyZGYwY2E0MDZjOTUzYmQwNDM5NTU4IDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0
cy9DaGFuZ2VMb2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTMgQEAK
KzIwMTAtMTEtMjQgIERpbWl0cmkgR2xhemtvdiAgPGRnbGF6a292QGNocm9taXVtLm9yZz4KKwor
ICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBSRUdSRVNTSU9O
IChyNzE5MzQpOiBNYWluIHNlYXJjaCBmaWVsZCBhdCBBcHBsZSB0ZWNoIHNwZWNzIGRvZXMgbm90
IGFjY2VwdCB0eXBpbmcKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcu
Y2dpP2lkPTQ5ODY4CisKKyAgICAgICAgKiBmYXN0L2Zvcm1zL2Rpc2FibGVkLXNlYXJjaC1pbnB1
dC1leHBlY3RlZC50eHQ6IEFkZGVkLgorICAgICAgICAqIGZhc3QvZm9ybXMvZGlzYWJsZWQtc2Vh
cmNoLWlucHV0Lmh0bWw6IEFkZGVkLgorCiAyMDEwLTExLTIzICBJbHlhIFRpa2hvbm92c2t5ICA8
bG9pc2xvQGNocm9taXVtLm9yZz4KIAogICAgICAgICBVbnJldmlld2VkLiBVcGRhdGVkIGNocm9t
aXVtIGV4cGVjdGF0aW9ucy4KZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL2Zhc3QvZm9ybXMvZGlz
YWJsZWQtc2VhcmNoLWlucHV0LWV4cGVjdGVkLnR4dCBiL0xheW91dFRlc3RzL2Zhc3QvZm9ybXMv
ZGlzYWJsZWQtc2VhcmNoLWlucHV0LWV4cGVjdGVkLnR4dApuZXcgZmlsZSBtb2RlIDEwMDY0NApp
bmRleCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwLi5mNTE3NWFiNDA5
YzEzM2EwOGVjMTgwZmQyZTc4YjRmMTgzMzBkOWNjCi0tLSAvZGV2L251bGwKKysrIGIvTGF5b3V0
VGVzdHMvZmFzdC9mb3Jtcy9kaXNhYmxlZC1zZWFyY2gtaW5wdXQtZXhwZWN0ZWQudHh0CkBAIC0w
LDAgKzEsMiBAQAorCitUaGUgaW5uZXIgdGV4dCBlbGVtZW50IG9mIHRoZSBzZWFyY2ggaW5wdXQg
c2hvdWxkIG5ldmVyIGJlIDAtaGVpZ2h0OiBQQVNTCmRpZmYgLS1naXQgYS9MYXlvdXRUZXN0cy9m
YXN0L2Zvcm1zL2Rpc2FibGVkLXNlYXJjaC1pbnB1dC5odG1sIGIvTGF5b3V0VGVzdHMvZmFzdC9m
b3Jtcy9kaXNhYmxlZC1zZWFyY2gtaW5wdXQuaHRtbApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRl
eCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwLi41NmYzZmVlZTFmMmMz
NTJkMDk4Yjk1N2JhYjc3ZDc1ODljMGMwOWQwCi0tLSAvZGV2L251bGwKKysrIGIvTGF5b3V0VGVz
dHMvZmFzdC9mb3Jtcy9kaXNhYmxlZC1zZWFyY2gtaW5wdXQuaHRtbApAQCAtMCwwICsxLDU4IEBA
Cis8aHRtbD4KKzxoZWFkPgorPHNjcmlwdD4KKworaWYgKHdpbmRvdy5sYXlvdXRUZXN0Q29udHJv
bGxlcikgeworICAgIGxheW91dFRlc3RDb250cm9sbGVyLmR1bXBBc1RleHQoKTsKKyAgICBsYXlv
dXRUZXN0Q29udHJvbGxlci53YWl0VW50aWxEb25lKCk7Cit9CisKK3ZhciBsb2dEaXY7CisKK2Z1
bmN0aW9uIGxvZyhtc2csIHN1Y2Nlc3MpCit7CisgICAgbG9nRGl2LmFwcGVuZENoaWxkKGRvY3Vt
ZW50LmNyZWF0ZUVsZW1lbnQoJ2RpdicpKS50ZXh0Q29udGVudCA9IG1zZyArICc6ICcgKyAoISFz
dWNjZXNzID8gJ1BBU1MnIDogJ0ZBSUwnKTsKK30KKworZnVuY3Rpb24gY2xpY2tPbihlbGVtZW50
KQoreworICAgIGlmICghd2luZG93LmV2ZW50U2VuZGVyKQorICAgICAgICByZXR1cm47CisKKyAg
ICB2YXIgeCA9IGVsZW1lbnQub2Zmc2V0TGVmdCArIGVsZW1lbnQub2Zmc2V0V2lkdGggLyAyOwor
ICAgIHZhciB5ID0gZWxlbWVudC5vZmZzZXRUb3AgKyBlbGVtZW50Lm9mZnNldEhlaWdodCAvIDI7
CisgICAgZXZlbnRTZW5kZXIubW91c2VNb3ZlVG8oeCwgeSk7CisgICAgZXZlbnRTZW5kZXIubW91
c2VEb3duKCk7CisgICAgZXZlbnRTZW5kZXIubW91c2VVcCgpOworfQorCitmdW5jdGlvbiBydW5U
ZXN0KCkKK3sKKyAgICBsb2dEaXYgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnY29uc29sZScp
OworICAgIHZhciBpbnB1dCA9IGRvY3VtZW50LmdldEVsZW1lbnRzQnlUYWdOYW1lKCdpbnB1dCcp
WzBdOworICAgIHNldFRpbWVvdXQoZnVuY3Rpb24oKSB7CisgICAgICAgIGlucHV0LmRpc2FibGVk
ID0gZmFsc2U7CisgICAgICAgIGlmICghd2luZG93LmV2ZW50U2VuZGVyKQorICAgICAgICAgICAg
cmV0dXJuOworCisgICAgICAgIHZhciB4ID0gaW5wdXQub2Zmc2V0TGVmdCArIGlucHV0Lm9mZnNl
dFdpZHRoIC8gMjsKKyAgICAgICAgdmFyIHkgPSBpbnB1dC5vZmZzZXRUb3AgKyBpbnB1dC5vZmZz
ZXRIZWlnaHQgLyAyOworICAgICAgICBldmVudFNlbmRlci5tb3VzZU1vdmVUbyh4LCB5KTsKKyAg
ICAgICAgZXZlbnRTZW5kZXIubW91c2VEb3duKCk7CisgICAgICAgIGV2ZW50U2VuZGVyLm1vdXNl
VXAoKTsKKyAgICAgICAgZXZlbnRTZW5kZXIua2V5RG93bignYScpOworICAgICAgICBsb2coJ1Ro
ZSBpbm5lciB0ZXh0IGVsZW1lbnQgb2YgdGhlIHNlYXJjaCBpbnB1dCBzaG91bGQgbmV2ZXIgYmUg
MC1oZWlnaHQnLCBpbnB1dC52YWx1ZSA9PSAnYScpOworICAgICAgICBsYXlvdXRUZXN0Q29udHJv
bGxlci5ub3RpZnlEb25lKCk7CisgICAgfSwgMCk7Cit9CisKKzwvc2NyaXB0PgorPC9oZWFkPgor
PGJvZHkgb25sb2FkPSJydW5UZXN0KCkiPgorICAgIDxkaXY+CisgICAgICAgIDxpbnB1dCBpZD0i
Zm9vIiB0eXBlPSJzZWFyY2giIHJlc3VsdHM9IjAiIGRpc2FibGVkPgorICAgIDwvZGl2PgorPGRp
diBpZD0iY29uc29sZSI+Cis8L2Rpdj4KKzwvYm9keT4KKzwvaHRtbD4KXCBObyBuZXdsaW5lIGF0
IGVuZCBvZiBmaWxlCmRpZmYgLS1naXQgYS9XZWJDb3JlL0NoYW5nZUxvZyBiL1dlYkNvcmUvQ2hh
bmdlTG9nCmluZGV4IDA3M2I4ZDRjZjI2NDg2NDU5NTI5YTNjN2IzMGU1MTU2MmNkOGE3NDkuLjZk
ZjU5Yjk4MDMxYmFiZDcyMTgwNzZiMDQzMjgyY2I5MjRiNjU4YWIgMTAwNjQ0Ci0tLSBhL1dlYkNv
cmUvQ2hhbmdlTG9nCisrKyBiL1dlYkNvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTUgQEAKKzIw
MTAtMTEtMjQgIERpbWl0cmkgR2xhemtvdiAgPGRnbGF6a292QGNocm9taXVtLm9yZz4KKworICAg
ICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBSRUdSRVNTSU9OIChy
NzE5MzQpOiBNYWluIHNlYXJjaCBmaWVsZCBhdCBBcHBsZSB0ZWNoIHNwZWNzIGRvZXMgbm90IGFj
Y2VwdCB0eXBpbmcKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dp
P2lkPTQ5ODY4CisKKyAgICAgICAgVGVzdDogZmFzdC9mb3Jtcy9kaXNhYmxlZC1zZWFyY2gtaW5w
dXQuaHRtbAorCisgICAgICAgICogcmVuZGVyaW5nL1RleHRDb250cm9sSW5uZXJFbGVtZW50cy5j
cHA6CisgICAgICAgIChXZWJDb3JlOjpSZW5kZXJUZXh0Q29udHJvbElubmVyQmxvY2s6Omhhc0xp
bmVJZkVtcHR5KToKKwogMjAxMC0xMS0yMyAgQWRhbSBCZXJna3Zpc3QgIDxhZGFtLmJlcmdrdmlz
dEBlcmljc3Nvbi5jb20+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgTWFydGluIFJvYmluc29uLgpk
aWZmIC0tZ2l0IGEvV2ViQ29yZS9yZW5kZXJpbmcvVGV4dENvbnRyb2xJbm5lckVsZW1lbnRzLmNw
cCBiL1dlYkNvcmUvcmVuZGVyaW5nL1RleHRDb250cm9sSW5uZXJFbGVtZW50cy5jcHAKaW5kZXgg
YmE0YzdiYjg1MDY1N2FjZjk1Y2MzZDIwNmFkMzdmNTU2OTJkNjdhNi4uMTAxNTU5ZmY5ZTNhMWMx
NzBhYWY4YjYyZWYyOTEzZmQxZTVmNjYwMyAxMDA2NDQKLS0tIGEvV2ViQ29yZS9yZW5kZXJpbmcv
VGV4dENvbnRyb2xJbm5lckVsZW1lbnRzLmNwcAorKysgYi9XZWJDb3JlL3JlbmRlcmluZy9UZXh0
Q29udHJvbElubmVyRWxlbWVudHMuY3BwCkBAIC01MSw2ICs1MSw4IEBAIGNsYXNzIFJlbmRlclRl
eHRDb250cm9sSW5uZXJCbG9jayA6IHB1YmxpYyBSZW5kZXJCbG9jayB7CiBwdWJsaWM6CiAgICAg
UmVuZGVyVGV4dENvbnRyb2xJbm5lckJsb2NrKE5vZGUqIG5vZGUsIGJvb2wgaXNNdWx0aUxpbmUp
IDogUmVuZGVyQmxvY2sobm9kZSksIG1fbXVsdGlMaW5lKGlzTXVsdGlMaW5lKSB7IH0KIAorICAg
IHZpcnR1YWwgYm9vbCBoYXNMaW5lSWZFbXB0eSgpIGNvbnN0IHsgcmV0dXJuIHRydWU7IH0KKwog
cHJpdmF0ZToKICAgICB2aXJ0dWFsIFZpc2libGVQb3NpdGlvbiBwb3NpdGlvbkZvclBvaW50KGNv
bnN0IEludFBvaW50Jik7CiAK
</data>
<flag name="review"
          id="65512"
          type_id="1"
          status="+"
          setter="darin"
    />
          </attachment>
      

    </bug>

</bugzilla>