In frameset changing innerHTML causes dissapearence of alternative titles.
Reported by
timurtro...@gmail.com,
Nov 27 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce the problem: 1. Make a simple frameset with two frames: frame1, frame2. 2. In frame1 make a div (div1) with a certain "title" attribute 3. In frame2 also make a div (div2) 3. In frame2 make a simple JS function with setTimeout/setInterval to change the innerHTML of div2 (say, once per second - as a clock) 4. On pointing the mouse cursor on div1 the title window will come out as usual, but immediately dissapear as the setTimeout/setInterval event runs. What is the expected behavior? The title window should not dissapear on timer firing. What went wrong? The title window dissapears every time the timer function changes innerHTML of the div2. Did this work before? Yes Chrome version: 62.0.3202.94 Channel: stable OS Version: 10.0 Flash Version: Files with sample code attached.
,
Nov 27 2017
It was all working fine at least one month ago (maybe, two weeks). Is it enough to narrow the regression range?
,
Nov 27 2017
,
Nov 28 2017
"Unable to reproduce the isuue on the reported chrome version 62.0.3202.94 and on the latest canary 64.0.3279.0 using windows 10 with the below mentioned steps. 1. Launched chrome 2. Downloaded and opened all the files in comment#0 We observed that no window is disappearing while the timer is running. Attaching the screen cast of the same. @Reporter: Could you please check the screen cast and let us know whether we missed any steps in reproducing the issue. Thanks!"
,
Nov 28 2017
Moreover, it is even enough just to go over frame2 with mouse cursor, clicking is not neccessary.
,
Nov 28 2017
Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 28 2017
The same bug appears in Chrome (62.something) on two different machines - Windows and Ubuntu
,
Nov 29 2017
"Able to reproduce the issue on reported chrome version 62.0.3202.94 and on the latest canary 64.0.3279.0 using Mac 10.12.6, Ubuntu 14.04 and Windows 10. Bisect Info: ================ Good build: 62.0.3186.0 Bad build: 62.0.3187.0 CHANGELOG URL: You are probably looking for a change made after 494615 (known good), but no later than 494616 (first known bad). https://chromium.googlesource.com/chromium/src/+log/a7482a88d73040a616ef53294eeef75ca8b6c5a2..2e27e8ef7352fa68de51b0c59257604c66b9781d suspect:https://chromium-review.googlesource.com/615424 Suspecting same from changelog. @dtapuska: Please confirm the issue and help in re-assigning if it is not related to your change. Note: Adding stable blocker for M-64 and requesting to merge the fix( (if its safe merge) to M-63. Thanks!"
,
Dec 1 2017
,
Dec 4 2017
,
Dec 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3759ce9f7db0a23f57ca007cf6247cead49c867c commit 3759ce9f7db0a23f57ca007cf6247cead49c867c Author: Dave Tapuska <dtapuska@chromium.org> Date: Fri Dec 08 21:39:41 2017 Reset the last known mouse mousing on MouseLeave Reset the last known mouse position to be unknown when we get a mouse leave or when the target of an iframe changes. BUG= 788690 Change-Id: Ib0c6ab3281b1bcdd5401fd51004c4f3e5a1c04b6 Reviewed-on: https://chromium-review.googlesource.com/814696 Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org> Commit-Queue: Dave Tapuska <dtapuska@chromium.org> Cr-Commit-Position: refs/heads/master@{#522877} [modify] https://crrev.com/3759ce9f7db0a23f57ca007cf6247cead49c867c/third_party/WebKit/Source/core/input/EventHandler.cpp [modify] https://crrev.com/3759ce9f7db0a23f57ca007cf6247cead49c867c/third_party/WebKit/Source/core/input/EventHandlerTest.cpp [modify] https://crrev.com/3759ce9f7db0a23f57ca007cf6247cead49c867c/third_party/WebKit/Source/core/input/MouseEventManager.cpp [modify] https://crrev.com/3759ce9f7db0a23f57ca007cf6247cead49c867c/third_party/WebKit/Source/core/input/MouseEventManager.h
,
Dec 8 2017
,
Jan 30 2018
Issue 806329 has been merged into this issue.
,
Jan 30 2018
In latest chrome update (64.0.3282.119 Windows 32 bit) bug is still present.
,
Jan 30 2018
Dear developers, this is quite a critical bug for us. Can you please tell when can we expect this fix to be merged into Chrome update?!
,
Jan 30 2018
It is marked as fixed in M65. Did you try that channel?
,
Feb 4 2018
No idea how it is "marked", the fact is, that in Chrome latest version on Windows and on Linux the bug is still reproduced.
,
Feb 4 2018
Bugs are marked as fixed when the change lands in the code branch. Not when the change ends up in a release. If is available in m65. So it should be in the beta, Dev and canary channels. Not the stable channel since it is still m64.
,
Mar 7 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by krajshree@chromium.org
, Nov 27 2017