817641 - Page doesn't load when searching from the search charm until the search panel is dismissed

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Brian R. Bondy [:bbondy]]

For some reason Firefox doesn't load the search result until the search pane is dismissed.  Whereas Chrome and IE10 both show the search results as soon as they are submitted even before the panel is dismissed.

This bug is to show the search results as soon as they are submitted.

Comment 1

[Brian R. Bondy [:bbondy]]

While working on the about flyout on the right of the screen, I noticed a similar issue.  If you put a 1s css transition on the visibility property of the flyout-container, and then you show the Metro settings pane. The Metro settings pane freezes the CSS transition completely until it is dismissed.

It seems like any Win8 UI at all completely freezes up our dispatching. 
We can maybe try adding a log statement into MetroAppShell::NativeCallback() to see if our event dispatching is hung

Comment 2

[Brian R. Bondy [:bbondy]]

I'll try investigating this and the CSS thing more if I have time after this iteration's bugs.

Comment 3

[Brian R. Bondy [:bbondy]]

Possibly related to bug 835615

Comment 4

[Brian R. Bondy [:bbondy]]

Update: Still debugging this.

I do notice that the page does fully load if you do a search and wait for a while before dismissing the pane.  It's just a painting issue of some sort.  Render() is being called with valid invalidation regions. Render() is not terminating early or showing any failures. 

Event processing for both gecko and native events is happening as well and works fine.  Next step is to setup some breakpoints for failures.  My best guess at this point is a problem inside the gfx code.  I know the gfx code does ignore some failures. 

Perhaps metro is forcing failure for the back buffer when we try to present it only when Metro UI is open.  I'll be working on this again more tomorrow.

Comment 5

[Brian R. Bondy [:bbondy]]

Still debugging this, the gfx code isn't throwing any errors by the way that I can find.

Something else strange I noticed. If you have a page with CSS animations like this one:
http://css-tricks.com/examples/CSS3Clock/

It freezes up as soon as metro UI appears.

Comment 6

[Brian R. Bondy [:bbondy]]

Attachment: Patch v1.

Got it! This will fix all of the problems we're having with our UI and Windows UI.

This took me forever to find because I didn't know which component the bug was in.  I checked widget event handling code, widget gfx code, gfx swap buffer code, view manager, refresh driver code, presentation shell code, and then that finally led me back to widget where the problem was.

The problem was just that invalidations were not being sent from view manager code because it thought that the widget was not visible because it was not activated when Metro UI was visible.  The fix was just to not assume activated is visible in widget code. Instead we track proper visibility status.

Comment 7

[Jim Mathies [:jimm]]

Comment on attachment 712074 [details] [diff] [review]
Patch v1.

(In reply to Brian R. Bondy [:bbondy] from comment #6)
> Created attachment 712074 [details] [diff] [review]
> Patch v1.
> 
> Got it! This will fix all of the problems we're having with our UI and
> Windows UI.
> 
> This took me forever to find because I didn't know which component the bug
> was in.  I checked widget event handling code, widget gfx code, gfx swap
> buffer code, view manager, refresh driver code, presentation shell code, and
> then that finally led me back to widget where the problem was.
> 
> The problem was just that invalidations were not being sent from view
> manager code because it thought that the widget was not visible because it
> was not activated when Metro UI was visible.  The fix was just to not assume
> activated is visible in widget code. Instead we track proper visibility
> status.

Sweet! So the window is deactivated when a system flyout is displayed?

Comment 8

[Brian R. Bondy [:bbondy]]

yup correct

Comment 9

[Brian R. Bondy [:bbondy]]

https://hg.mozilla.org/projects/elm/rev/1dea44445b78

Comment 10

[Brian R. Bondy [:bbondy]]

elm -> mc