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

RESOLVED FIXED

Status

()

Core
Widget: Win32
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: bbondy, Assigned: bbondy)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [metro-it2][LOE:1][metro-mvp])

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
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.
(Assignee)

Updated

5 years ago
Blocks: 801131
Whiteboard: [metro-it2][LOE:1][metro-mvp]

Updated

5 years ago
No longer blocks: 801131
(Assignee)

Comment 1

5 years ago
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
(Assignee)

Comment 2

5 years ago
I'll try investigating this and the CSS thing more if I have time after this iteration's bugs.
(Assignee)

Comment 3

5 years ago
Possibly related to bug 835615
(Assignee)

Comment 4

5 years ago
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.
(Assignee)

Comment 5

5 years ago
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.
(Assignee)

Comment 6

5 years ago
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.
Attachment #712074 - Flags: review?(jmathies)

Comment 7

5 years ago
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?
Attachment #712074 - Flags: review?(jmathies) → review+
(Assignee)

Comment 8

5 years ago
yup correct
(Assignee)

Comment 9

5 years ago
https://hg.mozilla.org/projects/elm/rev/1dea44445b78
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

5 years ago
elm -> mc
(Assignee)

Updated

5 years ago
Depends on: 835615
(Assignee)

Updated

5 years ago
Blocks: 835615
No longer depends on: 835615
(Assignee)

Updated

5 years ago
Duplicate of this bug: 835615
Blocks: 843742
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.