popstate event firing when no history state change is registered
Reported by
taylor.b...@gmail.com,
Sep 25 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. Launch Chrome 2. Open file provided 3. Click 'Activate' once to set current history state 4. Click 'Active' a second time What is the expected behavior? When the 'Activate' link is clicked the first time, the popstate event SHOULD fire, as the history state is mutated. When the 'Active' link is clicked a second time, the popstate event SHOULD NOT fire, as the history state does not change. What went wrong? On the second click of 'Active' a popstate event was fired. Did this work before? N/A Chrome version: 61.0.3163.100 Channel: stable OS Version: OS X 10.12.6 Flash Version:
,
Sep 26 2017
taylor.benner@ Thanks for the issue. Tested this issue on Windows 7 and Mac OS 10.12.6 using the latest Chrome Stable 61.0.3163.100 and latest Canary 63.0.3223.8 with the steps as show in the attached screen cast. Please can you help us understand us as what 'popstate event' mean and where to check the history state? Requesting you to please attach the screen cast of the steps followed for the better understanding of the issue. Thanks..
,
Sep 26 2017
I just retested on Version Chrome 61.0.3163.100 (Official Build) (64-bit) The issue is, to my understanding, as follows: From the documentation found on: https://developer.mozilla.org/en-US/docs/Web/Events/popstate "The popstate event is fired when the active history entry changes." In the screencast I have attached, you'll notice there is no discernible history changes. I show this by logging the history object to the console, as well as showing Chrome's history tab. One more place you can check, that I did not include in my screen cast, is right clicking on Chrome's back button to view page history. The test page I have provided has an event listener set on the window's "popstate" event. This event is emitted when the active history entry changes. Clicking an anchor link many times in a row should not affect the active history entry, thus the popstate event should not fire. In my screenscast, I show by using console.log that after the first two firings of the event, the history is no longer changing. Thus the event should not be firing. The bug should be categorized as "Javascript."
,
Sep 26 2017
Thank you for providing more feedback. Adding requester "susanjuniab@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 26 2017
,
Sep 27 2017
,
Sep 27 2017
taylor.benner@ - Thanks a lot for your clarification...!! Able to reproduce this issue on Mac 10.12.6, Win-10 and Ubuntu 14.04 using chrome reported version 61.0.3163.100 and latest canary #63.0.3223.8. This is a non-regression issue as it is observed from M50 old builds. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Nov 17 2017
,
Aug 1
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ligim...@chromium.org
, Sep 25 2017