<?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>118396</bug_id>
          
          <creation_ts>2013-07-04 11:08:05 -0700</creation_ts>
          <short_desc>[GTK] crash on WebKit::GtkAdjustmentWatcher::updateAdjustmentsFromScrollbars when destroying a webview</short_desc>
          <delta_ts>2013-07-24 07:37:51 -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>WebKitGTK</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>DUPLICATE</resolution>
          <dup_id>119003</dup_id>
          
          <bug_file_loc></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="Emilio Pozuelo Monfort">pochu27</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>cgarcia</cc>
    
    <cc>gdesmott</cc>
    
    <cc>gustavo</cc>
    
    <cc>mrobinson</cc>
    
    <cc>zan</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>906219</commentid>
    <comment_count>0</comment_count>
    <who name="Emilio Pozuelo Monfort">pochu27</who>
    <bug_when>2013-07-04 11:08:05 -0700</bug_when>
    <thetext>This is happening with webkitgtk+ 2.0.3, libwebkitgtk-3.0.so (so GTK+ 3 and not WebKit2)

I have an application that in certain situations creates a webview only to destroy it later (because a condition is met and we can&apos;t use it). This seems to trigger a race and later on the application crashes:

Program received signal SIGSEGV, Segmentation fault.
WebKit::core (webView=0x3fb999999999999a) at ../Source/WebKit/gtk/webkit/webkitwebview.cpp:5415
5415	../Source/WebKit/gtk/webkit/webkitwebview.cpp: No such file or directory.
(gdb) bt
#0  WebKit::core (webView=0x3fb999999999999a) at ../Source/WebKit/gtk/webkit/webkitwebview.cpp:5415
#1  0x00007ffff51798b8 in WebKit::GtkAdjustmentWatcher::updateAdjustmentsFromScrollbars (this=0x20f6540)
    at ../Source/WebKit/gtk/WebCoreSupport/GtkAdjustmentWatcher.cpp:65
#2  0x00007ffff5179939 in WebKit::updateAdjustmentCallback (
    watcher=&lt;error reading variable: value has been optimized out&gt;)
    at ../Source/WebKit/gtk/WebCoreSupport/GtkAdjustmentWatcher.cpp:76
#3  0x00007fffeff30fa3 in g_timeout_dispatch (source=source@entry=0x21015b0, callback=&lt;optimized out&gt;, 
    user_data=&lt;optimized out&gt;) at gmain.c:4413
#4  0x00007fffeff30446 in g_main_dispatch (context=0x65f500) at gmain.c:3054
#5  g_main_context_dispatch (context=context@entry=0x65f500) at gmain.c:3630
#6  0x00007fffeff30798 in g_main_context_iterate (context=context@entry=0x65f500, block=block@entry=1, 
    dispatch=dispatch@entry=1, self=&lt;optimized out&gt;) at gmain.c:3701
#7  0x00007fffeff3083c in g_main_context_iteration (context=0x65f500, context@entry=0x0, 
    may_block=may_block@entry=1) at gmain.c:3762
#8  0x00007ffff1096624 in g_application_run (application=0x68c110, argc=argc@entry=1, 
    argv=argv@entry=0x7fffffffdf58) at gapplication.c:1623
#9  0x0000000000409e76 in main (argc=1, argv=0x7fffffffdf58) at main.c:78
(gdb) 

This only happens about 10-20% of the time with one webview being created and quickly destroyed.

I have found these bugs which look like are hitting the same issue in webkitgtk+ and happen in different applications (empathy, epiphany, eclipse):

https://bugzilla.redhat.com/show_bug.cgi?id=928783
https://bugzilla.redhat.com/show_bug.cgi?id=869598
https://bugzilla.redhat.com/show_bug.cgi?id=874353</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>909676</commentid>
    <comment_count>1</comment_count>
    <who name="Emilio Pozuelo Monfort">pochu27</who>
    <bug_when>2013-07-18 02:33:08 -0700</bug_when>
    <thetext>14:18 &lt;       kov&gt; pochu, hmm, sounds like a bug indeed, you should probably make ChromeClientGtk&apos;s member be an OwnPtr&lt;GtkAdjustmentWatcher&gt;

I&apos;m not going to have time to work on this, in case somebody wants to pick it up.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>910671</commentid>
    <comment_count>2</comment_count>
      <attachid>207246</attachid>
    <who name="Guillaume Desmottes">gdesmott</who>
    <bug_when>2013-07-22 07:37:13 -0700</bug_when>
    <thetext>Created attachment 207246
fix</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>910834</commentid>
    <comment_count>3</comment_count>
    <who name="Martin Robinson">mrobinson</who>
    <bug_when>2013-07-22 14:57:26 -0700</bug_when>
    <thetext>Thanks for the patch! Unfortunately, based on the context here, I&apos;m not sure how this fixes the issue and it is missing a ChangeLog with a complete explanation. Please see https://www.webkit.org/coding/contributing.html for more information about the process of submitting fixes. 

With a bit of context, it will be easier for me to review the patch. The main issue I have at this point is that I do not know how switching the member to be allocated manually changes the semantics. It shouldn&apos;t as far as I can see.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>910919</commentid>
    <comment_count>4</comment_count>
    <who name="Carlos Garcia Campos">cgarcia</who>
    <bug_when>2013-07-22 23:53:04 -0700</bug_when>
    <thetext>I don&apos;t understand how the GtkAdjustmentWatcher can be alive after the web view is destroyed. And making it heap allocated shouldn&apos;t change anything, it will be deleted in the ChromeClient destructor.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>910930</commentid>
    <comment_count>5</comment_count>
    <who name="Guillaume Desmottes">gdesmott</who>
    <bug_when>2013-07-23 01:47:50 -0700</bug_when>
    <thetext>To be honest I don&apos;t really speak C++, Gustavo suggested me to try this fix and it worked. Best to ask him directly if you have any question.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>910940</commentid>
    <comment_count>6</comment_count>
    <who name="Carlos Garcia Campos">cgarcia</who>
    <bug_when>2013-07-23 02:04:03 -0700</bug_when>
    <thetext>I&apos;ve noticed something weird while looking at the GtkAdjustmentWatcher code. The idle source is not correctly reset in some cases, so I&apos;m not sure but the patch attached to bug #119003 could fix this problem. 

I think something like this could have happened:

1.- WebView is created
2.- updateAdjustmentsFromScrollbarsLater is called from ChromeClient::contentsSizeChanged. This method also schedules a web view resize
3.- web view size allocate is called before the update scrollbar idle source is called (since resize has higher priority than idle sources)
4.- size allocate calls GtkAdjustmentWatcher::updateAdjustmentsFromScrollbars that resets the idle source without actually destroying the source (see bug #119003)
5.- web view is destroyed and GtkAdjustmentWatcher too.
6.- update adjustments idle source callback is called.
7.- crash!

I guess it doesn&apos;t crash earlier because GtkAdjustmentWatcher is stack allocated so the pointer is still valid after it has been deleted. 

could someone try the patch in bug #119003 to see if the problem can be still reproduced?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>911024</commentid>
    <comment_count>7</comment_count>
    <who name="Guillaume Desmottes">gdesmott</who>
    <bug_when>2013-07-23 06:55:29 -0700</bug_when>
    <thetext>(In reply to comment #6)
&gt; could someone try the patch in bug #119003 to see if the problem can be still reproduced?

Indeed this patch seems to fix this bug as well. Feel free to close as a dup.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>911040</commentid>
    <comment_count>8</comment_count>
    <who name="Carlos Garcia Campos">cgarcia</who>
    <bug_when>2013-07-23 08:07:04 -0700</bug_when>
    <thetext>(In reply to comment #7)
&gt; (In reply to comment #6)
&gt; &gt; could someone try the patch in bug #119003 to see if the problem can be still reproduced?
&gt; 
&gt; Indeed this patch seems to fix this bug as well. Feel free to close as a dup.

Great, thanks for confirming, I guess using GOwnPtr fixed the problem because when heap allocated the pointer is set to 0 when destroyed, but the real problem (fixed in bug #119003) was still there.

*** This bug has been marked as a duplicate of bug 119003 ***</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>911297</commentid>
    <comment_count>9</comment_count>
    <who name="Gustavo Noronha (kov)">gustavo</who>
    <bug_when>2013-07-24 07:37:51 -0700</bug_when>
    <thetext>Err, I thought the adjustment watcher was already heap allocated and just not being deleted.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>207246</attachid>
            <date>2013-07-22 07:37:13 -0700</date>
            <delta_ts>2013-07-22 07:37:13 -0700</delta_ts>
            <desc>fix</desc>
            <filename>0001-GTK-ChromeClientGtk-store-the-GtkAdjustmentWatcher-a.patch</filename>
            <type>text/plain</type>
            <size>4996</size>
            <attacher name="Guillaume Desmottes">gdesmott</attacher>
            
              <data encoding="base64">RnJvbSA2NzViYmYzYThlZjRmNDllOWM3MThjZDc0NjMzYTAxYzkxYTJmZDI0IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBHdWlsbGF1bWUgRGVzbW90dGVzIDxndWlsbGF1bWUuZGVzbW90
dGVzQGNvbGxhYm9yYS5jby51az4KRGF0ZTogTW9uLCAyMiBKdWwgMjAxMyAxNjozNTozOCArMDIw
MApTdWJqZWN0OiBbUEFUQ0hdIFtHVEtdIENocm9tZUNsaWVudEd0azogc3RvcmUgdGhlIEd0a0Fk
anVzdG1lbnRXYXRjaGVyIGFzIGEKIE93blB0cgoKVGhlIEd0a0FkanVzdG1lbnRXYXRjaGVyIHNo
b3VsZCBub3Qgc3Vydml2ZSB0aGUgQ2hyb21lQ2xpZW50R3RrLgoKRml4IGh0dHBzOi8vYnVncy53
ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xMTgzOTYKLS0tCiBTb3VyY2UvV2ViS2l0L2d0ay9X
ZWJDb3JlU3VwcG9ydC9DaHJvbWVDbGllbnRHdGsuY3BwIHwgMTQgKysrKysrKy0tLS0tLS0KIFNv
dXJjZS9XZWJLaXQvZ3RrL1dlYkNvcmVTdXBwb3J0L0Nocm9tZUNsaWVudEd0ay5oICAgfCAgNiAr
KysrLS0KIDIgZmlsZXMgY2hhbmdlZCwgMTEgaW5zZXJ0aW9ucygrKSwgOSBkZWxldGlvbnMoLSkK
CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L2d0ay9XZWJDb3JlU3VwcG9ydC9DaHJvbWVDbGll
bnRHdGsuY3BwIGIvU291cmNlL1dlYktpdC9ndGsvV2ViQ29yZVN1cHBvcnQvQ2hyb21lQ2xpZW50
R3RrLmNwcAppbmRleCA5MGU3NjM2Li5jZTU5MTdmIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0
L2d0ay9XZWJDb3JlU3VwcG9ydC9DaHJvbWVDbGllbnRHdGsuY3BwCisrKyBiL1NvdXJjZS9XZWJL
aXQvZ3RrL1dlYkNvcmVTdXBwb3J0L0Nocm9tZUNsaWVudEd0ay5jcHAKQEAgLTExNiw3ICsxMTYs
NyBAQCBzdGF0aWMgUGFzc093blB0cjxXaWRnZXRCYWNraW5nU3RvcmU+IGNyZWF0ZUJhY2tpbmdT
dG9yZShHdGtXaWRnZXQqIHdpZGdldCwgY29ucwogCiBDaHJvbWVDbGllbnQ6OkNocm9tZUNsaWVu
dChXZWJLaXRXZWJWaWV3KiB3ZWJWaWV3KQogICAgIDogbV93ZWJWaWV3KHdlYlZpZXcpCi0gICAg
LCBtX2FkanVzdG1lbnRXYXRjaGVyKHdlYlZpZXcpCisgICAgLCBtX2FkanVzdG1lbnRXYXRjaGVy
KGFkb3B0UHRyKG5ldyBHdGtBZGp1c3RtZW50V2F0Y2hlcih3ZWJWaWV3KSkpCiAgICAgLCBtX2Ns
b3NlU29vblRpbWVyKDApCiAgICAgLCBtX2Rpc3BsYXlUaW1lcih0aGlzLCAmQ2hyb21lQ2xpZW50
OjpwYWludCkKICAgICAsIG1fZm9yY2VQYWludChmYWxzZSkKQEAgLTY2Myw3ICs2NjMsNyBAQCB2
b2lkIENocm9tZUNsaWVudDo6aW52YWxpZGF0ZUNvbnRlbnRzQW5kUm9vdFZpZXcoY29uc3QgSW50
UmVjdCYgdXBkYXRlUmVjdCwgYm9vbAogCiB2b2lkIENocm9tZUNsaWVudDo6aW52YWxpZGF0ZUNv
bnRlbnRzRm9yU2xvd1Njcm9sbChjb25zdCBJbnRSZWN0JiB1cGRhdGVSZWN0LCBib29sIGltbWVk
aWF0ZSkKIHsKLSAgICBtX2FkanVzdG1lbnRXYXRjaGVyLnVwZGF0ZUFkanVzdG1lbnRzRnJvbVNj
cm9sbGJhcnNMYXRlcigpOworICAgIG1fYWRqdXN0bWVudFdhdGNoZXIuZ2V0KCktPnVwZGF0ZUFk
anVzdG1lbnRzRnJvbVNjcm9sbGJhcnNMYXRlcigpOwogCiAjaWYgVVNFKEFDQ0VMRVJBVEVEX0NP
TVBPU0lUSU5HKQogICAgIEFjY2VsZXJhdGVkQ29tcG9zaXRpbmdDb250ZXh0KiBhY0NvbnRleHQg
PSBtX3dlYlZpZXctPnByaXYtPmFjY2VsZXJhdGVkQ29tcG9zaXRpbmdDb250ZXh0LmdldCgpOwpA
QCAtNjc4LDcgKzY3OCw3IEBAIHZvaWQgQ2hyb21lQ2xpZW50OjppbnZhbGlkYXRlQ29udGVudHNG
b3JTbG93U2Nyb2xsKGNvbnN0IEludFJlY3QmIHVwZGF0ZVJlY3QsIGJvCiAKIHZvaWQgQ2hyb21l
Q2xpZW50OjpzY3JvbGwoY29uc3QgSW50U2l6ZSYgZGVsdGEsIGNvbnN0IEludFJlY3QmIHJlY3RU
b1Njcm9sbCwgY29uc3QgSW50UmVjdCYgY2xpcFJlY3QpCiB7Ci0gICAgbV9hZGp1c3RtZW50V2F0
Y2hlci51cGRhdGVBZGp1c3RtZW50c0Zyb21TY3JvbGxiYXJzTGF0ZXIoKTsKKyAgICBtX2FkanVz
dG1lbnRXYXRjaGVyLmdldCgpLT51cGRhdGVBZGp1c3RtZW50c0Zyb21TY3JvbGxiYXJzTGF0ZXIo
KTsKIAogI2lmIFVTRShBQ0NFTEVSQVRFRF9DT01QT1NJVElORykKICAgICBBY2NlbGVyYXRlZENv
bXBvc2l0aW5nQ29udGV4dCogY29tcG9zaXRpbmdDb250ZXh0ID0gbV93ZWJWaWV3LT5wcml2LT5h
Y2NlbGVyYXRlZENvbXBvc2l0aW5nQ29udGV4dC5nZXQoKTsKQEAgLTczOSw3ICs3MzksNyBAQCBQ
bGF0Zm9ybVBhZ2VDbGllbnQgQ2hyb21lQ2xpZW50OjpwbGF0Zm9ybVBhZ2VDbGllbnQoKSBjb25z
dAogCiB2b2lkIENocm9tZUNsaWVudDo6Y29udGVudHNTaXplQ2hhbmdlZChGcmFtZSogZnJhbWUs
IGNvbnN0IEludFNpemUmIHNpemUpIGNvbnN0CiB7Ci0gICAgaWYgKG1fYWRqdXN0bWVudFdhdGNo
ZXIuc2Nyb2xsYmFyc0Rpc2FibGVkKCkpCisgICAgaWYgKG1fYWRqdXN0bWVudFdhdGNoZXIuZ2V0
KCktPnNjcm9sbGJhcnNEaXNhYmxlZCgpKQogICAgICAgICByZXR1cm47CiAKICAgICAvLyBXZSBu
ZWVkIHRvIHF1ZXVlIGEgcmVzaXplIHJlcXVlc3Qgb25seSBpZiB0aGUgc2l6ZSBjaGFuZ2VkLApA
QCAtNzU1LDcgKzc1NSw3IEBAIHZvaWQgQ2hyb21lQ2xpZW50Ojpjb250ZW50c1NpemVDaGFuZ2Vk
KEZyYW1lKiBmcmFtZSwgY29uc3QgSW50U2l6ZSYgc2l6ZSkgY29uc3QKICAgICAvLyBJZiB0aGlz
IHdhcyBhIG1haW4gZnJhbWUgc2l6ZSBjaGFuZ2UsIHVwZGF0ZSB0aGUgc2Nyb2xsYmFycy4KICAg
ICBpZiAoZnJhbWUgIT0gZnJhbWUtPnBhZ2UoKS0+bWFpbkZyYW1lKCkpCiAgICAgICAgIHJldHVy
bjsKLSAgICBtX2FkanVzdG1lbnRXYXRjaGVyLnVwZGF0ZUFkanVzdG1lbnRzRnJvbVNjcm9sbGJh
cnNMYXRlcigpOworICAgIG1fYWRqdXN0bWVudFdhdGNoZXIuZ2V0KCktPnVwZGF0ZUFkanVzdG1l
bnRzRnJvbVNjcm9sbGJhcnNMYXRlcigpOwogfQogCiB2b2lkIENocm9tZUNsaWVudDo6c2Nyb2xs
YmFyc01vZGVEaWRDaGFuZ2UoKSBjb25zdApAQCAtMTAxNSw3ICsxMDE1LDcgQEAgdm9pZCBDaHJv
bWVDbGllbnQ6OmVudGVyRnVsbFNjcmVlbkZvckVsZW1lbnQoV2ViQ29yZTo6RWxlbWVudCogZWxl
bWVudCkKICAgICBtX2Z1bGxTY3JlZW5FbGVtZW50ID0gZWxlbWVudDsKIAogICAgIGVsZW1lbnQt
PmRvY3VtZW50KCktPndlYmtpdFdpbGxFbnRlckZ1bGxTY3JlZW5Gb3JFbGVtZW50KGVsZW1lbnQp
OwotICAgIG1fYWRqdXN0bWVudFdhdGNoZXIuZGlzYWJsZUFsbFNjcm9sbGJhcnMoKTsKKyAgICBt
X2FkanVzdG1lbnRXYXRjaGVyLmdldCgpLT5kaXNhYmxlQWxsU2Nyb2xsYmFycygpOwogICAgIGd0
a193aW5kb3dfZnVsbHNjcmVlbihHVEtfV0lORE9XKHdpbmRvdykpOwogICAgIGVsZW1lbnQtPmRv
Y3VtZW50KCktPndlYmtpdERpZEVudGVyRnVsbFNjcmVlbkZvckVsZW1lbnQoZWxlbWVudCk7CiB9
CkBAIC0xMDUyLDcgKzEwNTIsNyBAQCB2b2lkIENocm9tZUNsaWVudDo6ZXhpdEZ1bGxTY3JlZW5G
b3JFbGVtZW50KFdlYkNvcmU6OkVsZW1lbnQqKQogCiAgICAgbV9mdWxsU2NyZWVuRWxlbWVudC0+
ZG9jdW1lbnQoKS0+d2Via2l0V2lsbEV4aXRGdWxsU2NyZWVuRm9yRWxlbWVudChtX2Z1bGxTY3Jl
ZW5FbGVtZW50LmdldCgpKTsKICAgICBndGtfd2luZG93X3VuZnVsbHNjcmVlbihHVEtfV0lORE9X
KHdpbmRvdykpOwotICAgIG1fYWRqdXN0bWVudFdhdGNoZXIuZW5hYmxlQWxsU2Nyb2xsYmFycygp
OworICAgIG1fYWRqdXN0bWVudFdhdGNoZXIuZ2V0KCktPmVuYWJsZUFsbFNjcm9sbGJhcnMoKTsK
ICAgICBtX2Z1bGxTY3JlZW5FbGVtZW50LT5kb2N1bWVudCgpLT53ZWJraXREaWRFeGl0RnVsbFNj
cmVlbkZvckVsZW1lbnQobV9mdWxsU2NyZWVuRWxlbWVudC5nZXQoKSk7CiAgICAgbV9mdWxsU2Ny
ZWVuRWxlbWVudC5jbGVhcigpOwogfQpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdC9ndGsvV2Vi
Q29yZVN1cHBvcnQvQ2hyb21lQ2xpZW50R3RrLmggYi9Tb3VyY2UvV2ViS2l0L2d0ay9XZWJDb3Jl
U3VwcG9ydC9DaHJvbWVDbGllbnRHdGsuaAppbmRleCAzOGZjMTQ2Li5hNjcwOWI4IDEwMDY0NAot
LS0gYS9Tb3VyY2UvV2ViS2l0L2d0ay9XZWJDb3JlU3VwcG9ydC9DaHJvbWVDbGllbnRHdGsuaAor
KysgYi9Tb3VyY2UvV2ViS2l0L2d0ay9XZWJDb3JlU3VwcG9ydC9DaHJvbWVDbGllbnRHdGsuaApA
QCAtMjEsNiArMjEsOCBAQAogI2lmbmRlZiBDaHJvbWVDbGllbnRHdGtfaAogI2RlZmluZSBDaHJv
bWVDbGllbnRHdGtfaAogCisjaW5jbHVkZSA8d3RmL093blB0ci5oPgorCiAjaW5jbHVkZSAiQ2hy
b21lQ2xpZW50LmgiCiAjaW5jbHVkZSAiR3RrQWRqdXN0bWVudFdhdGNoZXIuaCIKICNpbmNsdWRl
ICJJbnRSZWN0LmgiCkBAIC00Myw3ICs0NSw3IEBAIG5hbWVzcGFjZSBXZWJLaXQgewogICAgIGNs
YXNzIENocm9tZUNsaWVudCA6IHB1YmxpYyBXZWJDb3JlOjpDaHJvbWVDbGllbnQgewogICAgIHB1
YmxpYzoKICAgICAgICAgQ2hyb21lQ2xpZW50KFdlYktpdFdlYlZpZXcqKTsKLSAgICAgICAgR3Rr
QWRqdXN0bWVudFdhdGNoZXIqIGFkanVzdG1lbnRXYXRjaGVyKCkgeyByZXR1cm4gJm1fYWRqdXN0
bWVudFdhdGNoZXI7IH0KKyAgICAgICAgR3RrQWRqdXN0bWVudFdhdGNoZXIqIGFkanVzdG1lbnRX
YXRjaGVyKCkgeyByZXR1cm4gbV9hZGp1c3RtZW50V2F0Y2hlci5nZXQoKTsgfQogCiAgICAgICAg
IHZpcnR1YWwgdm9pZCBjaHJvbWVEZXN0cm95ZWQoKTsKIApAQCAtMTY2LDcgKzE2OCw3IEBAIG5h
bWVzcGFjZSBXZWJLaXQgewogCiAgICAgcHJpdmF0ZToKICAgICAgICAgV2ViS2l0V2ViVmlldyog
bV93ZWJWaWV3OwotICAgICAgICBHdGtBZGp1c3RtZW50V2F0Y2hlciBtX2FkanVzdG1lbnRXYXRj
aGVyOworICAgICAgICBPd25QdHI8R3RrQWRqdXN0bWVudFdhdGNoZXI+IG1fYWRqdXN0bWVudFdh
dGNoZXI7CiAgICAgICAgIEtVUkwgbV9ob3ZlcmVkTGlua1VSTDsKICAgICAgICAgdW5zaWduZWQg
aW50IG1fY2xvc2VTb29uVGltZXI7CiAKLS0gCjEuOC4xLjQKCg==
</data>

          </attachment>
      

    </bug>

</bugzilla>