Obsolete
Status Update
No update yet.
Comments
vi...@chromium.org
This is an automated update generated by script.
ka...@chromium.org
mhathorn@ thanks for the issue.
Tested the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.102 using chrome latest stable version 40.0.2272.101,41.02272.104 and canary 43.0.2353.0.
1.Created and load the html page with the above code snippet.
2.Open dev tools console clicked on preserve log check box
3.Navigated away form the tab by clicking the another tab from address bar
4.Refresh the tab see the message as PageHide listener called in console.
Not able to reproduce the issue.Please find the attached screen cast for the same.
Could you please check the issue with fresh profile and update the thread if the issue still persists.Please provide the screen cast to triage the issue further.
Tested the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.102 using chrome latest stable version 40.0.2272.101,41.02272.104 and canary 43.0.2353.0.
1.Created and load the html page with the above code snippet.
2.Open dev tools console clicked on preserve log check box
3.Navigated away form the tab by clicking the another tab from address bar
4.Refresh the tab see the message as PageHide listener called in console.
Not able to reproduce the issue.Please find the attached screen cast for the same.
Could you please check the issue with fresh profile and update the thread if the issue still persists.Please provide the screen cast to triage the issue further.
mh...@google.com
pageHide isn't supposed to be fired when the page isn't visible, despite its name (it confuses everyone!). It's supposed to be fired when you navigate away from the page - for example, by clicking on a link or typing a new URL in the address bar. It's *not* supposed to be fired when you hide the page by going to another tab or minimizing Chrome.
However, if you do navigate away from the page (e.g. by clicking on a link) you *should* see "PageHide listener called" in the console. The fact that you *do not* see it means that you *can* reproduce the bug. Navigating away from the page should produce the exact same behavior (with respect to this event) as reloading the page currently does.
Please let me know if this helps explain the behavior I'm trying to describe. If you need further clarification, I'll go ahead and try to create a screencast to show what's not happening.
However, if you do navigate away from the page (e.g. by clicking on a link) you *should* see "PageHide listener called" in the console. The fact that you *do not* see it means that you *can* reproduce the bug. Navigating away from the page should produce the exact same behavior (with respect to this event) as reloading the page currently does.
Please let me know if this helps explain the behavior I'm trying to describe. If you need further clarification, I'll go ahead and try to create a screencast to show what's not happening.
ka...@chromium.org
Thanks for the update.
Please find the attached screen cast and confirm.
Means When we click on link ex:google in console it is not showing the information as "PageHide listener is called".
Please provide the screen cast for better understanding if anything missed from my end.
Appreciate your help!
Please find the attached screen cast and confirm.
Means When we click on link ex:google in console it is not showing the information as "PageHide listener is called".
Please provide the screen cast for better understanding if anything missed from my end.
Appreciate your help!
mh...@google.com
That's correct - this reproduces the behavior I'm reporting in this bug.
rn...@chromium.org
========================================
Good Build:
40.0.2214.111 Base Position: 303346
Bad Build:
41.0.2272.101 Base Position: 310958
=======================================
Able to repro this issue on Windows 7, 8, 8.1, MAC (10.10.3) & Ubuntu (14.04) for the Google Chrome Stable Version - 43.0.2357.130
This is a regression issue broken in M40, below mentioned is the bisect info:
CHANGELOG URL:http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=305615%3A305619
Suspecting Commit - ead20f1a85c6cb6f3faf6042bea56126a7078854
Review URL:https://codereview.chromium.org/734053003
@lukasza: Could you please have a look into the issue, and if it has nothing to do with your changes, please do assign it to the concerned owner.
Thank you.
Good Build:
40.0.2214.111 Base Position: 303346
Bad Build:
41.0.2272.101 Base Position: 310958
=======================================
Able to repro this issue on Windows 7, 8, 8.1, MAC (10.10.3) & Ubuntu (14.04) for the Google Chrome Stable Version - 43.0.2357.130
This is a regression issue broken in M40, below mentioned is the bisect info:
CHANGELOG URL:
Suspecting Commit - ead20f1a85c6cb6f3faf6042bea56126a7078854
Review URL:
@lukasza: Could you please have a look into the issue, and if it has nothing to do with your changes, please do assign it to the concerned owner.
Thank you.
la...@chromium.org
This issue likely requires triage. The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days). Thanks for helping out!
-Anthony
-Anthony
lu...@chromium.org
Oops, sorry for a late response - not sure how this bug slipped under my radar.
Anyway - the CL mentioned inhttps://crbug.com/chromium/472282#c6 only affects behavior of a Chrome Remote Desktop host process - this CL cannot affect Chrome behavior and therefore cannot cause the regression raised in this bug.
Anyway - the CL mentioned in
pa...@chromium.org
[Empty comment from Monorail migration]
ha...@chromium.org
Not V8 related
ko...@chromium.org
[Empty comment from Monorail migration]
rn...@chromium.org
Could someone from Dev team please look into this issue, since I was getting the same bisect range as mentioned in the https://crbug.com/chromium/472282#c6
Thank you.
Thank you.
ro...@robwu.nl
I did a bisect using the onload event. The unload event DOES fire, but the console.log messages are not printed any more as of Chrome 41.
Bisect result:https://chromium.googlesource.com/chromium/src/+log/ea732bdd614d286483a04499b57844be5f1c3e4a..65e008fd79d83908525452783452e69af8e7299c
This has only one commit, 65e008fd79d83908525452783452e69af8e7299c (https://codereview.chromium.org/744653002 ).
STR:
1. Create index.html and put it on localhost:
<script>
window.addEventListener('unload', function() { console.log('BYE'); });
</script>
2. Visithttp://localhost/index.html
3. Open the developer tools, console, and tick the Preserve log upon navigation checkbox.
4. Navigate toexample.com via the omnibox (this induces a process swap for the renderer).
Expected result:
- "BYE" is shown in the console.
Actual result:
- Nothing is printed in the console.
Note: if the navigation from step 4 is induced via the page (e.g. by JavaScript), then the same process is re-used and the bug does not occur.
I confirmed that the unload event DOES get triggered, by performing a synchronous request from the unload handler, and observing that the request indeed shows up in the access log on localhost:
<script>
window.addEventListener('unload', function() {
console.log('BYE');
var x = new XMLHttpRequest();
x.open('GET', '/?unload', false);
x.send();
});
</script>
Bisect result:
This has only one commit, 65e008fd79d83908525452783452e69af8e7299c (
STR:
1. Create index.html and put it on localhost:
<script>
window.addEventListener('unload', function() { console.log('BYE'); });
</script>
2. Visit
3. Open the developer tools, console, and tick the Preserve log upon navigation checkbox.
4. Navigate to
Expected result:
- "BYE" is shown in the console.
Actual result:
- Nothing is printed in the console.
Note: if the navigation from step 4 is induced via the page (e.g. by JavaScript), then the same process is re-used and the bug does not occur.
I confirmed that the unload event DOES get triggered, by performing a synchronous request from the unload handler, and observing that the request indeed shows up in the access log on localhost:
<script>
window.addEventListener('unload', function() {
console.log('BYE');
var x = new XMLHttpRequest();
x.open('GET', '/?unload', false);
x.send();
});
</script>
yu...@chromium.org
[Empty comment from Monorail migration]
cb...@chromium.org
[Empty comment from Monorail migration]
[Monorail components: -Blink]
[Monorail components: -Blink]
lu...@chromium.org
[Empty comment from Monorail migration]
se...@chromium.org
[Empty comment from Monorail migration]
pf...@chromium.org
[Empty comment from Monorail migration]
je...@gmail.com
Works fine on Firefox, but not on Chrome.
ca...@gmail.com
is it possible that such few people are affected by this? I cannot manage to use pagehide at all on chrome!
ha...@chromium.org
mkwst@ my guess is this is intentional behavior. WDYT?
ha...@chromium.org
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]>
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.
Sorry for the inconvenience if the bug really should have been left as Available.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Sorry for the inconvenience if the bug really should have been left as Available.
For more details visit
bm...@chromium.org
I'm closing this as WAI, since in 5 years, no substantial progress was made on this, and it looks like there's no real plan what the behavior should be / whether this is actually a bug.
sa...@wikimedia.org
As far as I can tell this violates the spec [0].
In the test case that I used [1], I confirmed that the pageshow event fires during navigation. If the pageshow event has fired the document’s page showing flag should have been set to true, and therefore the pagehide event should be fired when the document is unloaded.
I also noticed that the visibilitychange event is not fired when the document is unloaded, which also violates the spec. This bug has been reported and fixed before [2] but may have been reintroduced.
My motivation for bumping this bug is that it currently impacts MediaWiki’s EventLogging extension. The extension provides client-side analytics event logging capabilities. It is currently enabled on all MediaWiki wikis hosted by the Wikimedia Foundation.
At the time of writing, the EventLogging client queues analytics events for sending and flushes the queue:
1. Every 30 seconds;
2. When the document’s visibility state changes to “hidden”; or
3. When the pagehide event is fired
If neither 2 and 3 are happening when the document is unloaded, then the queue will not be flushed and analytics events will be lost.
Could this issue be reopened or should I create a new one?
[0]https://html.spec.whatwg.org/multipage/browsing-the-web.html#unloading-documents
[1]https://phabricator.wikimedia.org/T314924#8148554
[2]https://bugs.chromium.org/p/chromium/issues/detail?id=554834
In the test case that I used [1], I confirmed that the pageshow event fires during navigation. If the pageshow event has fired the document’s page showing flag should have been set to true, and therefore the pagehide event should be fired when the document is unloaded.
I also noticed that the visibilitychange event is not fired when the document is unloaded, which also violates the spec. This bug has been reported and fixed before [2] but may have been reintroduced.
My motivation for bumping this bug is that it currently impacts MediaWiki’s EventLogging extension. The extension provides client-side analytics event logging capabilities. It is currently enabled on all MediaWiki wikis hosted by the Wikimedia Foundation.
At the time of writing, the EventLogging client queues analytics events for sending and flushes the queue:
1. Every 30 seconds;
2. When the document’s visibility state changes to “hidden”; or
3. When the pagehide event is fired
If neither 2 and 3 are happening when the document is unloaded, then the queue will not be flushed and analytics events will be lost.
Could this issue be reopened or should I create a new one?
[0]
[1]
[2]
sa...@wikimedia.org
I forgot to mention that my Chrome version is 104.0.5112.79.
sa...@wikimedia.org
Happily, a colleague of mine, Timo Tijhof, was able to determine that this appears to be a problem with DevTools not showing the log entries. I then confirmed that Chrome is sending beacon requests from the pagehide event listener but they also aren't showing up in either the console or the Network tab.
I'll look around for an issue for the network requests part and if I don't find one then I'll create one.
My apologies for the disruption.
I'll look around for an issue for the network requests part and if I don't find one then I'll create one.
My apologies for the disruption.
is...@google.com
This issue was migrated from crbug.com/chromium/472282?no_tracker_redirect=1
[Monorail components added to Component Tags custom field.]
[Monorail components added to Component Tags custom field.]
Description
Steps to reproduce the problem:
1. Load the following page:
<!DOCTYPE html>
<html>
<head>
<title>Test PageHide Page</title>
</head>
<body>
<p><a href="
<script>
console.log('Script loaded.');
window.addEventListener('pagehide', function() {
console.log('PageHide listener called.');
});
</script>
</body>
</html>
(this behavior can also be reproduced by listening for unload instead of pagehide).
2. Open the console in developer tools and turn on Preserve log.
3. Navigate away from the page, either by clicking on the link or by typing in the address bar.
What is the expected behavior?
I expect to see "PageHide listener called" in the console.
What went wrong?
I do not see anything in the console.
Did this work before? Yes As recently as version 40.0.2214.111 (64-bit)
Chrome version: 41.0.2272.101 Channel: stable
OS Version:
Flash Version: Shockwave Flash 17.0 r0
I can also report by putting a breakpoint in the pagehide event handler that it does not get fired when the tab is closed. However, the pagehide handler does fire when reloading the page.
All the above comments also apply to the unload event handler.