Issue metadata
Sign in to add a comment
|
Regression: Language drop down menu does not open on clicking in support.google.com.
Reported by
lpa...@etouch.net,
Oct 26 2016
|
||||||||||||||||||||||
Issue descriptionChrome Version: 56.0.2900.0 (Official Build) 1e4fbec3b5701d9f605e88f14dafa442be98b648-refs/heads/master@{#427219} 32/64 Bit. OS: Windows (7,8,10) Test URL: https://support.google.com/chrome/answer/185277?visit_id=0-636130663558892363-3231639120&p=settings_sign_in&rd=1 Steps: 1. Launch chrome and navigate to above url. 2. Scroll down the web page and click on the language drop down menu, observe. Actual: Language drop down menu does not open on clicking. Expected: Language drop down menu should open on clicking. This is a regression issue broken in M-56, will soon update the other info. Manual Regression Range: Good Build: 56.0.2886.0 Bad Build: 56.0.2888.0 Note: Issue is windows specific not seen in Mac and Linux OS.
,
Oct 26 2016
Below are the bisect details for the same: Bisect Info: =========== Good build:56.0.2886.0, Revision Range(424099) Bad build: 56.0.2889.0, Revision Range(424926) After executing the bisect script, i got the following CL's between good and bad build versions ============================================ https://chromium.googlesource.com/chromium/src/+log/150be4b2b4d10d0bd5a552ff76802b2d15950ec6..629a5d065848adbac50931ae305a3d8597578e4d The suspecting Change Log is : ----------- https://chromium.googlesource.com/chromium/src/+/629a5d065848adbac50931ae305a3d8597578e4d From the above CL suspecting the below change https://codereview.chromium.org/2393323005 sdy@- Could you please look into this issue, if it's related to your change? if not could you please help us to reassign this issue to the right owner. Thanks.!
,
Oct 27 2016
> From the above CL suspecting the below change > https://codereview.chromium.org/2393323005 It's a Mac-only change. It can't cause this Windows-specific issue. Please bisect again.
,
Oct 27 2016
Re-bisected the issue getting following narrow bisect: https://chromium.googlesource.com/chromium/src/+log/136a7131948b4adc886e8da7ddfac54c2ae8b1b8..ecf8bb9b85922dbed58632e269d579deb06ef58b?pretty=fuller&n=100 Suspecting: 424123 ? @atimoxin@yandex-team.ru : Please take a look.
,
Oct 28 2016
,
Oct 28 2016
Yes, this bug caused by my patch (424123). I suggested a fix in https://crrev.com/2454053004 There is a bug with the same reason: http://crbug.com/655984
,
Oct 28 2016
And this bug should be reproducible only for maximized windows (not fullscreen or normal window mode).
,
Oct 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6279588b7ebc740f85409107dd91b5c3ce628065 commit 6279588b7ebc740f85409107dd91b5c3ce628065 Author: atimoxin <atimoxin@yandex-team.ru> Date: Fri Oct 28 14:51:37 2016 Don't apply maximized window bounds workaround if bounds aren't changed In HWNDMessageHandler::OnWindowPosChanging() was added code that restores correct maximized window's bounds after attaching or detaching additional display (see crrev.com/6bb7f8192). But this workaround also applied if OnWindowPosChanging() was called with SWP_NOMOVE/SWP_NOSIZE flags that leads to bugs such as crbug.com/659525 and crbug.com/655984 . This CL adds additional check for SWP_NOMOVE/SWP_NOSIZE flags before applying workaround and fixes this bugs. BUG= 659525 , 655984 Review-Url: https://codereview.chromium.org/2454053004 Cr-Commit-Position: refs/heads/master@{#428368} [modify] https://crrev.com/6279588b7ebc740f85409107dd91b5c3ce628065/ui/views/win/hwnd_message_handler.cc
,
Nov 1 2016
Tested the issue on Windows 7 using chrome Dev version-56.0.2906.0 with the steps mentioned in comment #0.Language drop down menu opened successfully upon clicking. Please find the attached screen cast for the same. Adding TE-Verified labels. Thanks,
,
Nov 1 2016
,
Nov 7 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/deb38c53aaeb0ca533daf90abe4f46536df1661b commit deb38c53aaeb0ca533daf90abe4f46536df1661b Author: sky <sky@chromium.org> Date: Mon Nov 07 18:06:42 2016 Revert of Don't apply maximized window bounds workaround if bounds aren't changed (patchset #1 id:1 of https://codereview.chromium.org/2454053004/ ) Reason for revert: This resulted in a shortcut to move between monitors not working. See 656001. Original issue's description: > Don't apply maximized window bounds workaround if bounds aren't changed > > In HWNDMessageHandler::OnWindowPosChanging() was added code that > restores correct maximized window's bounds after attaching or detaching > additional display (see crrev.com/6bb7f8192). But this workaround also > applied if OnWindowPosChanging() was called with SWP_NOMOVE/SWP_NOSIZE > flags that leads to bugs such as crbug.com/659525 and crbug.com/655984 . > > This CL adds additional check for SWP_NOMOVE/SWP_NOSIZE flags before > applying workaround and fixes this bugs. > > BUG= 659525 , 655984 > > Committed: https://crrev.com/6279588b7ebc740f85409107dd91b5c3ce628065 > Cr-Commit-Position: refs/heads/master@{#428368} TBR=atimoxin@yandex-team.ru # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 659525 , 655984 Review-Url: https://codereview.chromium.org/2482933002 Cr-Commit-Position: refs/heads/master@{#430314} [modify] https://crrev.com/deb38c53aaeb0ca533daf90abe4f46536df1661b/ui/views/win/hwnd_message_handler.cc |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by tkonch...@chromium.org
, Oct 26 2016Status: Untriaged (was: Unconfirmed)