Issue metadata
Sign in to add a comment
|
Regression: Unnecessary 'Add account' text is seen on drop down in print preview.
Reported by
rk...@etouch.net,
Mar 23 2016
|
||||||||||||||||||||||
Issue descriptionChrome Version : 50.0.2661.49 Revision a37d846dd7fa3234a8ccca5ea8d88006bff78c25-refs/branch-heads/2661@{#352}(32/64 bit) OS: Windows(Win-7 Aero Enabled) Precondition: Sign in into chrome with valid credentials. What steps will reproduce the problem? (1) Launch chrome,open NTP and give print command by Ctrl+P (2) Click on 'Change' button under 'Destination', click on drop down of 'Showing destination for'. (3) Now press down arrow key('Add account' text seen on drop down), open NTP and come back to preview page and observe. After switch back to print preview page,Unnecessary 'Add account' text is seen on drop down. The present account name should be seen on drop down and sign in page should be open. This is a regression issue,broken in 'M-43', below is manual bisect range: Good Build: 43.0.2355.0 Bad Build: 43.02356.0 Narrow Bisect: https://chromium.googlesource.com/chromium/src/+log/dd7a6481ef8d32d3e5814935d4acc9ed0cf13efc..43e98a61f0a66ba6a1bcc9db71eba84e4a703b73?pretty=fuller&n=100 Suspecting: r323640 Note: Issue is not seen on Mac and Linux OS. @tbarzic: Please help me to reassign this issue if your change is not cause for it.
,
Mar 23 2016
seems more like https://src.chromium.org/viewvc/blink?revision=193034&view=revision The issue is also seen if there is more then one account and the provisional selection in step 3. is not the one whose print destinations are displayed in the destination selection UI. When coming back to print preview page, the value in the select element will not match the rest of the UI.
,
Mar 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/831776ec4a98f781dc8ce20bb3346538fd59b8da commit 831776ec4a98f781dc8ce20bb3346538fd59b8da Author: keishi <keishi@chromium.org> Date: Fri Mar 25 11:39:01 2016 Popup loosing focus through keyboard events should update HTMLSelectElement display Ctrl-N while a popup menu is open, causes the window to loose focus, and ViewMsg_Close is sent to the popup widget. This causes WebPagePopupImpl::close to be called. Right now this causes the popup to close without updating the display from the provisional selection (ie HTMLSelectElement::indexToSelectOnCancel) to the actual selection. WebPagePopupImpl::close should use WebPagePopupImpl::cancel to handle that case properly. Loosing focus through mouse clicks were working because we manually call cancel from the mouse event handler. Regression caused by r193034 BUG= 597206 Review URL: https://codereview.chromium.org/1833843002 Cr-Commit-Position: refs/heads/master@{#383271} [modify] https://crrev.com/831776ec4a98f781dc8ce20bb3346538fd59b8da/third_party/WebKit/Source/web/WebPagePopupImpl.cpp
,
Mar 28 2016
,
Mar 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3223d00c477336a4a6d8af18dfc5fe24591e156d commit 3223d00c477336a4a6d8af18dfc5fe24591e156d Author: tkent <tkent@chromium.org> Date: Mon Mar 28 23:52:25 2016 Revert of Popup loosing focus through keyboard events should update HTMLSelectElement display (patchset #3 id:40001 of https://codereview.chromium.org/1833843002/ ) Reason for revert: Caused crashes; crbug.com/598291 Original issue's description: > Popup loosing focus through keyboard events should update HTMLSelectElement display > > Ctrl-N while a popup menu is open, causes the window to loose focus, and ViewMsg_Close is sent to the popup widget. > This causes WebPagePopupImpl::close to be called. > Right now this causes the popup to close without updating the display from the provisional selection (ie HTMLSelectElement::indexToSelectOnCancel) to the actual selection. > WebPagePopupImpl::close should use WebPagePopupImpl::cancel to handle that case properly. > > Loosing focus through mouse clicks were working because we manually call cancel from the mouse event handler. > > Regression caused by r193034 > > BUG= 597206 > > Committed: https://crrev.com/831776ec4a98f781dc8ce20bb3346538fd59b8da > Cr-Commit-Position: refs/heads/master@{#383271} TBR=keishi@chromium.org NOTRY=true BUG= 597206 , 598291 Review URL: https://codereview.chromium.org/1841623002 Cr-Commit-Position: refs/heads/master@{#383614} [modify] https://crrev.com/3223d00c477336a4a6d8af18dfc5fe24591e156d/third_party/WebKit/Source/web/WebPagePopupImpl.cpp
,
Mar 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ae1e3ad7ec33e9e4f0d47cd37c170ef51d478752 commit ae1e3ad7ec33e9e4f0d47cd37c170ef51d478752 Author: keishi <keishi@chromium.org> Date: Tue Mar 29 09:17:29 2016 Popup loosing focus through keyboard events should update HTMLSelectElement display Ctrl-N while a popup menu is open, causes the window to loose focus, and ViewMsg_Close is sent to the popup widget. This causes WebPagePopupImpl::close to be called. Right now this causes the popup to close without updating the display from the provisional selection (ie HTMLSelectElement::indexToSelectOnCancel) to the actual selection. WebPagePopupImpl::close should use WebPagePopupImpl::cancel to handle that case properly. Loosing focus through mouse clicks were working because we manually call cancel from the mouse event handler. Regression caused by r193034 BUG= 597206 Committed: https://crrev.com/831776ec4a98f781dc8ce20bb3346538fd59b8da Cr-Commit-Position: refs/heads/master@{#383271} Review URL: https://codereview.chromium.org/1833843002 Cr-Commit-Position: refs/heads/master@{#383691} [modify] https://crrev.com/ae1e3ad7ec33e9e4f0d47cd37c170ef51d478752/third_party/WebKit/Source/web/WebPagePopupImpl.cpp [modify] https://crrev.com/ae1e3ad7ec33e9e4f0d47cd37c170ef51d478752/third_party/WebKit/Source/web/WebViewImpl.cpp |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rk...@etouch.net
, Mar 23 2016