<?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>207256</bug_id>
          
          <creation_ts>2020-02-05 04:20:05 -0800</creation_ts>
          <short_desc>visibilitychange event does not get always fired on background but it may on foreground</short_desc>
          <delta_ts>2020-07-13 16:13:45 -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 JavaScript</component>
          <version>Safari 12</version>
          <rep_platform>iPhone / iPad</rep_platform>
          <op_sys>iOS 12</op_sys>
          <bug_status>NEW</bug_status>
          <resolution></resolution>
          
          <see_also>https://bugs.webkit.org/show_bug.cgi?id=205942</see_also>
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords>InRadar</keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Alexander Cerutti">cerutti.alexander</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>cdumez</cc>
    
    <cc>Kongpheng.Nanthavongsa</cc>
    
    <cc>webkit-bug-importer</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1614999</commentid>
    <comment_count>0</comment_count>
    <who name="Alexander Cerutti">cerutti.alexander</who>
    <bug_when>2020-02-05 04:20:05 -0800</bug_when>
    <thetext>Hello,
this is my first bug here and I&apos;m not too sure about the information I filled to report this problem, since I&apos;m not that into Webkit.

What I experienced is that I&apos;ve tried to attach a `visibilitychange` listener on my application. It contains a `console.log` and some logics that depend on `document.hidden`.
So, if home button or sleep button is pressed, the event is fired and we can see in the debugging console the log.

I&apos;ve been reported, and I&apos;ve verified, that sometimes this event is not fired when, for sure on iPad (also iOS 13), one of those two buttons are pressed. Instead the event is fired when Safari goes back in foreground. So the log gets printed twice. Moreover, sometimes `document.hidden` is `false` in both events. So if some logic is based on a check on that property, wrong code block may be run.

I wasn&apos;t able to find a steady way to reproduce this, and this seems to happen in different cases.
For example, I&apos;m developing a video player (here is where the event is created). We are importing a third-party video AD engine. What we experienced is that during some ADs, on home/sleep buttons, the event is not fired on background but twice on foreground. This happened also during other video contents playback, but I&apos;m not sure it is related to multimedia contents playback but instead on the amount of work the engine that is has to do when the buttons get pressed or some kind of concurrency problem on Safari background (but these are only thoughts of mine).

If I&apos;ll ever find more details I&apos;ll edit or add a comment to increase the details.
I hope this bug report is good enough (but I think this won&apos;t be) to find the problem.
Thank you.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1615085</commentid>
    <comment_count>1</comment_count>
      <attachid>389818</attachid>
    <who name="Alexander Cerutti">cerutti.alexander</who>
    <bug_when>2020-02-05 09:43:03 -0800</bug_when>
    <thetext>Created attachment 389818
Repro html page</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1615086</commentid>
    <comment_count>2</comment_count>
    <who name="Alexander Cerutti">cerutti.alexander</who>
    <bug_when>2020-02-05 09:43:11 -0800</bug_when>
    <thetext>I&apos;ve found a way to reproduce almost-steadly the problem while using sleep button.
With the sample that I&apos;m attaching, which is a normal video tag with a `visibilitychange` event attached on document, I&apos;ve tried to lock and unlock the iPad with iOS 12, different times.

The video was playing before this happened. Some unlocks (may vary from 3 to 5 or more), the video didn&apos;t came back to playing automatically and the `visibilitychanged` event started being fired only on foreground.
This situation can persist for some other lock-unlock actions but it will recover somehow and then can fall back in this again.

I don&apos;t know how this can be related or linked under the hood, but seems the only almost-steady way I found to reproduce this problem.

Instead, I didn&apos;t found yet a way to reproduce the problem that happens when home button is pressed.
Anyway, if the player is paused after unlock, pressing home button still fires the event `visibilitychanged`.
I think that they might be two different but related problems.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1615552</commentid>
    <comment_count>3</comment_count>
    <who name="Radar WebKit Bug Importer">webkit-bug-importer</who>
    <bug_when>2020-02-05 23:28:51 -0800</bug_when>
    <thetext>&lt;rdar://problem/59215749&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1657505</commentid>
    <comment_count>4</comment_count>
    <who name="Chris Dumez">cdumez</who>
    <bug_when>2020-05-29 16:29:54 -0700</bug_when>
    <thetext>Likely related to process suspension on iOS. When you lock the screen or home out of Safari, our processes get suspended shortly after. As a result, we may or may not have time to fire the visibilitychange event before we get suspended. The event normally gets fired when the process resumes if it did to have time to get fired before suspension.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1671216</commentid>
    <comment_count>5</comment_count>
    <who name="Kongpheng">Kongpheng.Nanthavongsa</who>
    <bug_when>2020-07-13 16:13:45 -0700</bug_when>
    <thetext>Any updates?  This bug is still reproducible on iOS 13.5.1.  I included a fiddle to reproduce the issue, without the need for a video element: https://jsfiddle.net/vkpheng/pv0omfrn/.

To reproduce:
* On iOS Safari, open this fiddle and run it
* Click Home button to background Safari
* Immediately click Safari icon to bring Safari back to the foreground
* Notice that no alert pops up

Expected: an alert pops up, since there was a visibility change.

Please advise.  Thanks!</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>389818</attachid>
            <date>2020-02-05 09:43:03 -0800</date>
            <delta_ts>2020-02-05 09:43:03 -0800</delta_ts>
            <desc>Repro html page</desc>
            <filename>index.html</filename>
            <type>text/html</type>
            <size>1487</size>
            <attacher name="Alexander Cerutti">cerutti.alexander</attacher>
            
              <data encoding="base64">PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuIj4KPGhlYWQ+Cgk8bWV0YSBjaGFyc2V0PSJV
VEYtOCI+Cgk8bWV0YSBuYW1lPSJ2aWV3cG9ydCIgY29udGVudD0id2lkdGg9ZGV2aWNlLXdpZHRo
LCBpbml0aWFsLXNjYWxlPTEuMCI+Cgk8bWV0YSBodHRwLWVxdWl2PSJYLVVBLUNvbXBhdGlibGUi
IGNvbnRlbnQ9ImllPWVkZ2UiPgoJPHRpdGxlPlZpc2liaWxpdHkgY2hhbmdlIHJlcHJvIG9uIHdl
YmtpdDwvdGl0bGU+CgoJPHN0eWxlPgoJCXZpZGVvIHsKCQkJd2lkdGg6IDUwMHB4OwoJCX0KCTwv
c3R5bGU+CjwvaGVhZD4KPGJvZHk+Cgk8dmlkZW8gc3JjPSJodHRwOi8vY29tbW9uZGF0YXN0b3Jh
Z2UuZ29vZ2xlYXBpcy5jb20vZ3R2LXZpZGVvcy1idWNrZXQvc2FtcGxlL0JpZ0J1Y2tCdW5ueS5t
cDQiIGNvbnRyb2xzPjwvdmlkZW8+Cgk8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CgkJ
Y29uc3QgdmlkZW9UYWcgPSBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFtZSgidmlkZW8iKVsw
XTsKCQl2aWRlb1RhZy5tdXRlZCA9IHRydWU7CgkJdmlkZW9UYWcudm9sdW1lID0gMDsKCgkJY29u
c29sZS5sb2coIlN0YXR1czoiKTsKCQljb25zb2xlLmxvZygiSGFzIHN1cHBvcnQgZm9yICdvbnZp
c2liaWxpdHljaGFuZ2UnIiwgIm9udmlzaWJpbGl0eWNoYW5nZSIgaW4gZG9jdW1lbnQpOwoKCQlj
b25zdCB2aXNpYmlsaXR5RXZlbnRXaXRoUHJlZml4ID0gKAoJCQkoZG9jdW1lbnQuaGlkZGVuICE9
PSB1bmRlZmluZWQgJiYgInZpc2liaWxpdHljaGFuZ2UiKSB8fAoJCQkoZG9jdW1lbnQubXNIaWRk
ZW4gIT09IHVuZGVmaW5lZCAmJiAibXN2aXNpYmlsaXR5Y2hhbmdlIikgfHwKCQkJKGRvY3VtZW50
LndlYmtpdEhpZGRlbiAhPT0gdW5kZWZpbmVkICYmICJ3ZWJraXR2aXNpYmlsaXR5Y2hhbmdlIikK
CQkpOwoKCQljb25zdCBoaWRkZW5XaXRoUHJlZml4ID0gKAoJCQkoZG9jdW1lbnQuaGlkZGVuICE9
PSB1bmRlZmluZWQgJiYgImhpZGRlbiIpIHx8CgkJCShkb2N1bWVudC5tc0hpZGRlbiAhPT0gdW5k
ZWZpbmVkICYmICJtc0hpZGRlbiIpIHx8CgkJCShkb2N1bWVudC53ZWJraXRIaWRkZW4gIT09IHVu
ZGVmaW5lZCAmJiAid2Via2l0SGlkZGVuIikKCQkpOwoKCQljb25zb2xlLmxvZygiQ2hvc2VuIGV2
ZW50OiIsIHZpc2liaWxpdHlFdmVudFdpdGhQcmVmaXgsIGhpZGRlbldpdGhQcmVmaXgpOwoKCQlk
b2N1bWVudC5hZGRFdmVudExpc3RlbmVyKHZpc2liaWxpdHlFdmVudFdpdGhQcmVmaXgsICgpID0+
IHsKCQkJY29uc29sZS5sb2coYCR7dmlzaWJpbGl0eUV2ZW50V2l0aFByZWZpeH0gaGFzIGJlZW4g
Y2FsbGVkIG5vdyAoJHtEYXRlLm5vdygpfSkuIEhpZGRlbjpgLCBkb2N1bWVudFtoaWRkZW5XaXRo
UHJlZml4XSk7CgkJCWNvbnNvbGUubG9nKCItLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tIikKCQl9KTsKCgkJdmlkZW9UYWcucGxheSgpOwoJPC9zY3JpcHQ+CjwvYm9keT4KPC9o
dG1sPgo=
</data>

          </attachment>
      

    </bug>

</bugzilla>