New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 902547 link

Starred by 2 users
Status: Fixed
Owner:
sky@chromium.org
Closed: Nov 28
Cc:
█ fsam...@chromium.org
dcasta...@chromium.org
sky@chromium.org
mustash-bugs@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Omnibox popup not painted correctly in single process mash

Project Member Reported by xiy...@chromium.org, Nov 6 
Saw it on Samus, r605757. See attached screenshot.

Works fine without single-process-mash and locally on dev box.

==== Window hierarchy ====

         DefaultContainer (0x1c8907ec1780) type=0 visible 0,0 1422x944 [snapped]
            BrowserFrame (0x1c890e6c7300) type=1 [active] visible 54,93 853x510 [snapped] subpixel offset=[-0.111109 -0.222219] remote_id=FrameSinkId(4294967295, 75)
               DesktopNativeWidgetAura - content window (0x1c890bb98600) type=0 [focused] visible 0,0 854x511 remote_id=FrameSinkId(4294967295, 76)
                  NativeViewHostAuraClip (0x1c890db3e000) type=0 visible 0,118 854x393 remote_id=FrameSinkId(4294967295, 79)
                     WebContentsViewAura (0x1c890dc78a80) type=0 visible 0,0 854x393 remote_id=FrameSinkId(4294967295, 77)
                        RenderWidgetHostViewAura (0x1c890db32780) type=0 visible 0,0 854x393 remote_id=FrameSinkId(4294967295, 78) ax_tree_id=58
            RoundedOmniboxResultsFrameWindow (0x1c890b993c00) type=2 visible 368,235 697x296 [snapped] subpixel offset=[-0.222202 0.000000] remote_id=FrameSinkId(4294967295, 82)
               DesktopNativeWidgetAura - content window (0x1c890b42d600) type=0 visible 0,0 698x297 remote_id=FrameSinkId(4294967295, 83)
            StatusBubble (0x1c890b993d80) type=2 51,581 284x22 [snapped] subpixel offset=[0.111114 0.111152] remote_id=FrameSinkId(4294967295, 80)
               DesktopNativeWidgetAura - content window (0x1c890bb30900) type=0 0,0 285x23 remote_id=FrameSinkId(4294967295, 81)
omnibox_popup.png
1017 KB View Download

Comment 1 by xiy...@chromium.org, Nov 6 

Repro steps:
1. Open a browser window and type something in omnibox to make the popup show up;
2. Drag the browser window around

At step 2, the popup should be closed. But on device, it stays where it was. Type again in omnibox would create another pop and you can have as many as you like.

Close the browser window and all pop-ups go away with it.

Comment 2 by xiy...@chromium.org, Nov 7 

This turns out to be that we somehow lost local surface id for the pop when it resizes. As a result, its compositor stops updating and holding all the animations.

Comment 3 by xiy...@chromium.org, Nov 8

Summary: Omnibox popup not painted correctly in single process mash (was: Omnibox popup is not destroyed in single process mash)
With msw@'s https://chromium-review.googlesource.com/c/chromium/src/+/1321867, the local surface is set correctly and the popup is closed.

Re-purpose this bug for the paint issue. Note that some area of the popup is not painted.

Comment 4 by xiy...@chromium.org, Nov 8

Cc: fsam...@chromium.org
+fsamuel

The painting problem turns out to be with the mask layer. I changed the popup background color in RoundedOmniboxResultsFrame [1] to see how the popup is painted. RoundedOmniboxResultsFrame is the contents view of the pop up widget. It paints correctly without the mask layer.

But with mask layer added and under single process mash, some area of the view is not painted. See the attached screenshots. The redness is the background color. The unpainted part shows whatever under the popup widget. The unpainted part changes when the device scale changes as shown in the two screensthops.

I am not sure why the mask layer + mash causes problem. Any insights?

[1] https://cs.chromium.org/chromium/src/chrome/browser/ui/views/omnibox/rounded_omnibox_results_frame.cc?rcl=4808ff32bc68877fde60e9fdb5d6725ee66ad5bc&l=135
omnibox_popup.png
84.6 KB View Download
omnibox_popup_1.png
113 KB View Download

Comment 5 by xiy...@chromium.org, Nov 8

Cc: dcasta...@chromium.org
+dcastagna for mask layer expertise

The problem is only repro'd on a real device. Running on dev box works fine. Add "--enable-features=SingleProcessMash" to /etc/chrome_dev.conf and you will see the problem.

Comment 6 by mpear...@chromium.org, Nov 12

Status: Assigned (was: Untriaged)
Untriaged -> Assigned in order to remove from omnibox triage queue.  It's clear xiyuan@ is the lead on this investigation.

Comment 7 by sky@google.com, Nov 14

Owner: sky@chromium.org

Comment 8 by sky@google.com, Nov 15

Status: Started (was: Assigned)
My suspicion is this is because the LayerTreeHostImpl that the browser is using is not configured the same as the one used by ash/classic.

Comment 9 by sky@chromium.org, Nov 28

Status: Fixed (was: Started)
This is fixed now. It was fixed by the work done in  bug 905569 . Most likely the addition of a RasterContextProvider ( https://chromium.googlesource.com/chromium/src.git/+/ea7742fa46f63572a4223223ac88f0a8853c803e ).
►

Sign in to add a comment