Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2804813002:
Hide popups when handling mouse down, mouse wheel, or gesture tap in a WebFrameWidget (Closed)
DescriptionHide popups when handling mouse down, mouse wheel, or gesture tap in a WebFrameWidget
When a mouse down is handled inside WebViewImpl (main frame), the current page
popup is hidden. The same behavior should apply to out of process renderers.
However, in OOPIF renderers the WebViewImpl does not handle mouse events and
the task is delegated to the WebFrameWidget corresponding to the frame which
has received the event. But since receiving and input inside a WebFrameWidget
suggests that the mouse down has been outside the bounds of the WebPagePopup,
we should dismiss any currently showing popups the same way as we do it for
WebViewImpls.
Specifically, not having this behavior led to a bug on Windows where date
picker inside OOPIFs does not show again after dismissing an older one by
clicking inside the OOPIF.
BUG=671732
Review-Url: https://codereview.chromium.org/2804813002
Cr-Commit-Position: refs/heads/master@{#466055}
Committed: https://chromium.googlesource.com/chromium/src/+/e3cbfeec943500d99832b93b015d62937ff15443
Patch Set 1 #Patch Set 2 : Rebased #Patch Set 3 : Applied the changes to WebMouseEvent #Patch Set 4 : Rebased #Patch Set 5 : Use Alt + Down instead of F4 #Patch Set 6 : Make sure a new popup is not generated #
Total comments: 8
Patch Set 7 : (Try to) Dismiss popup on scroll and gesture tap #
Total comments: 2
Patch Set 8 : Rebased (post blink rename) #Patch Set 9 : Cancel popup on mouse scroll #Patch Set 10 : Fix a compile error #Patch Set 11 : Fix a compile error (2) #
Total comments: 11
Patch Set 12 : Addressing comments #
Messages
Total messages: 64 (50 generated)
The CQ bit was checked by ekaramad@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by ekaramad@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by ekaramad@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by ekaramad@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by ekaramad@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
ekaramad@chromium.org changed reviewers: + dcheng@chromium.org, kenrb@chromium.org
Please take a look. Thanks!
The problem also occurs when I click on a different frame than the one with the open popup. It dismisses the popup but doesn't Does this patch fix that problem? In that case is the popup disappearing with its owner knowing about it, but then it calls hidePopup() only when you later click on the iframe?
On 2017/04/06 20:42:04, kenrb wrote: > The problem also occurs when I click on a different frame than the one with the > open popup. It dismisses the popup but doesn't > > Does this patch fix that problem? In that case is the popup disappearing with > its owner knowing about it, but then it calls hidePopup() only when you later > click on the iframe? Yes as in (like you mentioned) clicking back into the <iframe> actually destroys the WebPagePopupImpl. On Linux and (apparently also Mac) we send the mouse click to WebPagePopupImpl and since it is outside its bounds (whether or not inside the <iframe>), the popup is killed.
https://codereview.chromium.org/2804813002/diff/100001/third_party/WebKit/Sou... File third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp (right): https://codereview.chromium.org/2804813002/diff/100001/third_party/WebKit/Sou... third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp:775: // the current page popup for this process. Nit: I prefer the original comment (since it also describes why we save pagePopup) https://codereview.chromium.org/2804813002/diff/100001/third_party/WebKit/Sou... third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp:776: pagePopup = static_cast<WebPagePopupImpl*>(view()->pagePopup()); Let's take advantage of the fact that view() already returns a WebViewImpl and change pagePopup() to just return a WebPagePopupImpl for WebViewImpl. Covariant return types are allowed for virtual functions, so this should work. https://codereview.chromium.org/2804813002/diff/100001/third_party/WebKit/Sou... third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp:804: WebPagePopupImpl* pagePopupImpl = Nit: Call this currentPagePopup https://codereview.chromium.org/2804813002/diff/100001/third_party/WebKit/Sou... third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp:810: view()->hidePopups(); The logic in WebViewImpl calls cancel() -- is it OK to call a different method here?
This is maybe not an ideal state, because it is different from WebViewImpl::OnMouseDown's intent in that here you end up with a state where the popup has been dismissed but the WebViewImpl doesn't know it yet. That does not look to have been possible without OOPIFs. I can't find any specific problems that it causes, though, so maybe it is okay. Another issue mentioned on the bug that this doesn't fix: scrolling the frame doesn't cause the popup to get dismissed, as it does in non-OOPIFs. Is this because the scroll events aren't being passed to the main thread?
Description was changed from ========== Hide popups when handling mouse down inside WebFrameWidget When a mouse down is handled inside WebViewImpl (main frame), the current page popup is hidden. The same behavior should apply to out of process renderers. However, in OOPIF renderers the WebViewImpl does not handle mouse events and the task is delegated to the WebFrameWidget corresponding to the frame which has received the event. But since receiving and input inside a WebFrameWidget suggests that the mouse down has been outside the bounds of the WebPagePopup, we should dismiss any currently showing popups the same way as we do it for WebViewImpls. Specifically, not having this behavior led to a bug on Windows where date picker inside OOPIFs does not show again after dismissing an older one by clicking inside the OOPIF. BUG=671732 ========== to ========== Hide popups when handling mouse down inside WebFrameWidget When a mouse down is handled inside WebViewImpl (main frame), the current page popup is hidden. The same behavior should apply to out of process renderers. However, in OOPIF renderers the WebViewImpl does not handle mouse events and the task is delegated to the WebFrameWidget corresponding to the frame which has received the event. But since receiving and input inside a WebFrameWidget suggests that the mouse down has been outside the bounds of the WebPagePopup, we should dismiss any currently showing popups the same way as we do it for WebViewImpls. Specifically, not having this behavior led to a bug on Windows where date picker inside OOPIFs does not show again after dismissing an older one by clicking inside the OOPIF. BUG=671732 ==========
PTAL. https://codereview.chromium.org/2804813002/diff/100001/third_party/WebKit/Sou... File third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp (right): https://codereview.chromium.org/2804813002/diff/100001/third_party/WebKit/Sou... third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp:775: // the current page popup for this process. On 2017/04/07 06:32:01, dcheng wrote: > Nit: I prefer the original comment (since it also describes why we save > pagePopup) Acknowledged. https://codereview.chromium.org/2804813002/diff/100001/third_party/WebKit/Sou... third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp:776: pagePopup = static_cast<WebPagePopupImpl*>(view()->pagePopup()); On 2017/04/07 06:32:01, dcheng wrote: > Let's take advantage of the fact that view() already returns a WebViewImpl and > change pagePopup() to just return a WebPagePopupImpl for WebViewImpl. Covariant > return types are allowed for virtual functions, so this should work. Yes good idea. Thanks! https://codereview.chromium.org/2804813002/diff/100001/third_party/WebKit/Sou... third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp:804: WebPagePopupImpl* pagePopupImpl = On 2017/04/07 06:32:01, dcheng wrote: > Nit: Call this currentPagePopup Or I can just remove it now that view()->pagePopup() is a WebPagePopupImpl*. https://codereview.chromium.org/2804813002/diff/100001/third_party/WebKit/Sou... third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp:810: view()->hidePopups(); On 2017/04/07 06:32:01, dcheng wrote: > The logic in WebViewImpl calls cancel() -- is it OK to call a different method > here? hidePopups() simply calls cancelPagePopup(). That being said, I guess hidePopups() should be replaced by cancelPagePopup() in the public API. The reason is that hidePopups() used to call hideSelectPopup() or hideAutofill... amongs other things. But they are removed now, e.g., here https://codereview.chromium.org/1142303005 Now it simply calls cancelPagePopup() and I think its name is only as accurate as the comment above it in WebView.h (which is wrong): https://cs.chromium.org/chromium/src/third_party/WebKit/public/web/WebView.h?... https://codereview.chromium.org/2804813002/diff/120001/third_party/WebKit/Sou... File third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp (right): https://codereview.chromium.org/2804813002/diff/120001/third_party/WebKit/Sou... third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp:779: } There is a DCHECK(!m_pagePopup) which I could add here as well. https://codereview.chromium.org/2804813002/diff/120001/third_party/WebKit/Sou... third_party/WebKit/Source/web/WebFrameWidgetImpl.cpp:875: view()->hidePopups(); Unless there is a handler on the page, this won't work. kenrb@, should we add a fake handler for the local root like we do for WebViewImpl? Or drop this and redo the whole the main problem noted in https://crbug.com/566130)?
On 2017/04/07 14:27:47, kenrb wrote: > This is maybe not an ideal state, because it is different from > WebViewImpl::OnMouseDown's intent in that here you end up with a state where the > popup has been dismissed but the WebViewImpl doesn't know it yet. That does not > look to have been possible without OOPIFs. I can't find any specific problems > that it causes, though, so maybe it is okay. > > Another issue mentioned on the bug that this doesn't fix: scrolling the frame > doesn't cause the popup to get dismissed, as it does in non-OOPIFs. Is this > because the scroll events aren't being passed to the main thread? Yes I agree with both your points. For now this fixes the click and gesture tap issue. But generally the problem requires a major fix with some logic on the browser side maybe (to track the popup's RWH and then closing them for Windows or on scrolls).
LGTM with the CL description highlighted to note that this covers taps too now (and also highlight the remaining issues)
Description was changed from ========== Hide popups when handling mouse down inside WebFrameWidget When a mouse down is handled inside WebViewImpl (main frame), the current page popup is hidden. The same behavior should apply to out of process renderers. However, in OOPIF renderers the WebViewImpl does not handle mouse events and the task is delegated to the WebFrameWidget corresponding to the frame which has received the event. But since receiving and input inside a WebFrameWidget suggests that the mouse down has been outside the bounds of the WebPagePopup, we should dismiss any currently showing popups the same way as we do it for WebViewImpls. Specifically, not having this behavior led to a bug on Windows where date picker inside OOPIFs does not show again after dismissing an older one by clicking inside the OOPIF. BUG=671732 ========== to ========== Hide popups when handling mouse down and gesture tap inside WebFrameWidget When a mouse down is handled inside WebViewImpl (main frame), the current page popup is hidden. The same behavior should apply to out of process renderers. However, in OOPIF renderers the WebViewImpl does not handle mouse events and the task is delegated to the WebFrameWidget corresponding to the frame which has received the event. But since receiving and input inside a WebFrameWidget suggests that the mouse down has been outside the bounds of the WebPagePopup, we should dismiss any currently showing popups the same way as we do it for WebViewImpls. Specifically, not having this behavior led to a bug on Windows where date picker inside OOPIFs does not show again after dismissing an older one by clicking inside the OOPIF. BUG=671732 ==========
The CQ bit was checked by ekaramad@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by ekaramad@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: cast_shell_android on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...) cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...) linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by ekaramad@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_tsan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
The CQ bit was checked by ekaramad@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by ekaramad@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Hide popups when handling mouse down and gesture tap inside WebFrameWidget When a mouse down is handled inside WebViewImpl (main frame), the current page popup is hidden. The same behavior should apply to out of process renderers. However, in OOPIF renderers the WebViewImpl does not handle mouse events and the task is delegated to the WebFrameWidget corresponding to the frame which has received the event. But since receiving and input inside a WebFrameWidget suggests that the mouse down has been outside the bounds of the WebPagePopup, we should dismiss any currently showing popups the same way as we do it for WebViewImpls. Specifically, not having this behavior led to a bug on Windows where date picker inside OOPIFs does not show again after dismissing an older one by clicking inside the OOPIF. BUG=671732 ========== to ========== Hide popups when handling mouse down, mouse wheel, or gesture tap in a WebFrameWidget When a mouse down is handled inside WebViewImpl (main frame), the current page popup is hidden. The same behavior should apply to out of process renderers. However, in OOPIF renderers the WebViewImpl does not handle mouse events and the task is delegated to the WebFrameWidget corresponding to the frame which has received the event. But since receiving and input inside a WebFrameWidget suggests that the mouse down has been outside the bounds of the WebPagePopup, we should dismiss any currently showing popups the same way as we do it for WebViewImpls. Specifically, not having this behavior led to a bug on Windows where date picker inside OOPIFs does not show again after dismissing an older one by clicking inside the OOPIF. BUG=671732 ==========
ekaramad@chromium.org changed reviewers: + alexmos@chromium.org
Ken, could you please take another look? Thanks! Adding alexmos@ as the test owner. Alex, PTAL at the test file. Thanks!
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
lgtm with nits https://codereview.chromium.org/2804813002/diff/200001/chrome/browser/site_pe... File chrome/browser/site_per_process_interactive_browsertest.cc (right): https://codereview.chromium.org/2804813002/diff/200001/chrome/browser/site_pe... chrome/browser/site_per_process_interactive_browsertest.cc:1427: // Wait a tiny bit. In general, comments like this that describe easy-to-read code are discouraged. The guideline is to use comments to describe 'why', not 'what'. https://codereview.chromium.org/2804813002/diff/200001/chrome/browser/site_pe... chrome/browser/site_per_process_interactive_browsertest.cc:1442: // to make sure we never clicked into the date picker, get current date value nit: Capitalize start of comment. https://codereview.chromium.org/2804813002/diff/200001/third_party/WebKit/Sou... File third_party/WebKit/Source/web/WebViewImpl.cpp (right): https://codereview.chromium.org/2804813002/diff/200001/third_party/WebKit/Sou... third_party/WebKit/Source/web/WebViewImpl.cpp:1732: // TODO(kenrb): Popup coordination for out-of-process iframes needs to be I think this comment can be entirely removed. There are still changes needed but this method should be fine for OOPIFs.
Test LGTM with nits https://codereview.chromium.org/2804813002/diff/200001/chrome/browser/site_pe... File chrome/browser/site_per_process_interactive_browsertest.cc (right): https://codereview.chromium.org/2804813002/diff/200001/chrome/browser/site_pe... chrome/browser/site_per_process_interactive_browsertest.cc:1345: size_t GetNumberOfRenderWidgetHosts() { Perhaps put both helpers in an anonymous namespace on top? https://codereview.chromium.org/2804813002/diff/200001/chrome/browser/site_pe... chrome/browser/site_per_process_interactive_browsertest.cc:1394: // We use this to determine wether a new RenderWidgetHost is created or an old nit: s/wether/whether/ https://codereview.chromium.org/2804813002/diff/200001/chrome/browser/site_pe... chrome/browser/site_per_process_interactive_browsertest.cc:1442: // to make sure we never clicked into the date picker, get current date value nit: capitalize To
Thanks for the reviews! https://codereview.chromium.org/2804813002/diff/200001/chrome/browser/site_pe... File chrome/browser/site_per_process_interactive_browsertest.cc (right): https://codereview.chromium.org/2804813002/diff/200001/chrome/browser/site_pe... chrome/browser/site_per_process_interactive_browsertest.cc:1345: size_t GetNumberOfRenderWidgetHosts() { On 2017/04/18 19:59:49, alexmos (OOO until 5-2) wrote: > Perhaps put both helpers in an anonymous namespace on top? Done. Thanks for the suggestion. https://codereview.chromium.org/2804813002/diff/200001/chrome/browser/site_pe... chrome/browser/site_per_process_interactive_browsertest.cc:1394: // We use this to determine wether a new RenderWidgetHost is created or an old On 2017/04/18 19:59:49, alexmos (OOO until 5-2) wrote: > nit: s/wether/whether/ Thanks. Done. https://codereview.chromium.org/2804813002/diff/200001/chrome/browser/site_pe... chrome/browser/site_per_process_interactive_browsertest.cc:1427: // Wait a tiny bit. On 2017/04/18 19:25:53, kenrb wrote: > In general, comments like this that describe easy-to-read code are discouraged. > The guideline is to use comments to describe 'why', not 'what'. Noted. Thanks. I think I was just writing what I was thinking at the time. https://codereview.chromium.org/2804813002/diff/200001/chrome/browser/site_pe... chrome/browser/site_per_process_interactive_browsertest.cc:1442: // to make sure we never clicked into the date picker, get current date value On 2017/04/18 19:25:53, kenrb wrote: > nit: Capitalize start of comment. Done. Thanks. https://codereview.chromium.org/2804813002/diff/200001/third_party/WebKit/Sou... File third_party/WebKit/Source/web/WebViewImpl.cpp (right): https://codereview.chromium.org/2804813002/diff/200001/third_party/WebKit/Sou... third_party/WebKit/Source/web/WebViewImpl.cpp:1732: // TODO(kenrb): Popup coordination for out-of-process iframes needs to be On 2017/04/18 19:25:53, kenrb wrote: > I think this comment can be entirely removed. There are still changes needed but > this method should be fine for OOPIFs. Acknowledged.
The CQ bit was checked by ekaramad@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by ekaramad@chromium.org
The CQ bit was checked by ekaramad@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org, kenrb@chromium.org, alexmos@chromium.org Link to the patchset: https://codereview.chromium.org/2804813002/#ps220001 (title: "Addressing comments")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 220001, "attempt_start_ts": 1492707868799490,
"parent_rev": "7253ca232d77ec26c62c72bff4d9125e37bb8c58", "commit_rev":
"e3cbfeec943500d99832b93b015d62937ff15443"}
Message was sent while issue was closed.
Description was changed from ========== Hide popups when handling mouse down, mouse wheel, or gesture tap in a WebFrameWidget When a mouse down is handled inside WebViewImpl (main frame), the current page popup is hidden. The same behavior should apply to out of process renderers. However, in OOPIF renderers the WebViewImpl does not handle mouse events and the task is delegated to the WebFrameWidget corresponding to the frame which has received the event. But since receiving and input inside a WebFrameWidget suggests that the mouse down has been outside the bounds of the WebPagePopup, we should dismiss any currently showing popups the same way as we do it for WebViewImpls. Specifically, not having this behavior led to a bug on Windows where date picker inside OOPIFs does not show again after dismissing an older one by clicking inside the OOPIF. BUG=671732 ========== to ========== Hide popups when handling mouse down, mouse wheel, or gesture tap in a WebFrameWidget When a mouse down is handled inside WebViewImpl (main frame), the current page popup is hidden. The same behavior should apply to out of process renderers. However, in OOPIF renderers the WebViewImpl does not handle mouse events and the task is delegated to the WebFrameWidget corresponding to the frame which has received the event. But since receiving and input inside a WebFrameWidget suggests that the mouse down has been outside the bounds of the WebPagePopup, we should dismiss any currently showing popups the same way as we do it for WebViewImpls. Specifically, not having this behavior led to a bug on Windows where date picker inside OOPIFs does not show again after dismissing an older one by clicking inside the OOPIF. BUG=671732 Review-Url: https://codereview.chromium.org/2804813002 Cr-Commit-Position: refs/heads/master@{#466055} Committed: https://chromium.googlesource.com/chromium/src/+/e3cbfeec943500d99832b93b015d... ==========
Message was sent while issue was closed.
Committed patchset #12 (id:220001) as https://chromium.googlesource.com/chromium/src/+/e3cbfeec943500d99832b93b015d... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
