Last Comment Bug 523291 - Chrome initially sized wrong when restoring a maximized window
: Chrome initially sized wrong when restoring a maximized window
Product: Core
Classification: Components
Component: XUL (show other bugs)
: 1.9.2 Branch
: ARM Windows CE
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Neil Deakin
Depends on:
  Show dependency treegraph
Reported: 2009-10-19 21:21 PDT by nicksu
Modified: 2011-04-19 04:13 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

pic1 (106.64 KB, image/pjpeg)
2009-10-19 21:23 PDT, nicksu
no flags Details
Screengrab (239.63 KB, image/png)
2009-11-05 11:34 PST, Justin Dolske [:Dolske]
no flags Details

Description User image nicksu 2009-10-19 21:21:51 PDT
User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; WPS; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; eSobiSubscriber; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
Build Identifier: Mozilla/5.0 WinCE6.0 rv1.9.2a2 Gecko/20090920 Firefox/3.6a2

It only happened on the first time launch.

Reproducible: Always

Steps to Reproduce:
1.Install firefox
2.Launch firefox

Actual Results:  
Should not display garbage
Comment 1 User image nicksu 2009-10-19 21:23:27 PDT
Created attachment 407215 [details]
Comment 2 User image Justin Dolske [:Dolske] 2009-10-21 14:24:36 PDT
This looks more likely to be a video driver issue, since the garbage seems outside the window area. I'm not sure we do any kind of invalidation that would cause stripes like that...
Comment 3 User image nicksu 2009-10-21 19:33:38 PDT
We'll check that.
By the way, 
The firefox seems start from partial window to full screen.
If it possible to prevent this from firefox if it start from full screen?
Comment 4 User image Justin Dolske [:Dolske] 2009-10-21 19:42:42 PDT
I suspect that's a side effect of bug 504499.
Comment 5 User image Justin Dolske [:Dolske] 2009-10-25 19:08:40 PDT
I didn't see the garbage on the 9/24 OS build, but I do with the 10/16 build.
Comment 6 User image nicksu 2009-10-29 04:35:27 PDT
We also check in our device, old version didn't have this bug.
Comment 7 User image nicksu 2009-10-29 05:04:59 PDT
Forget about my previous comment #6.
We do detail test again, the same version (0920) 
didn't have this bug in old bsp.
We'll check what happen.
Comment 8 User image Justin Dolske [:Dolske] 2009-10-29 16:53:34 PDT
Thanks, let us know what you find.
Comment 9 User image Justin Dolske [:Dolske] 2009-11-01 14:44:12 PST
Additional note: marcia and I have both noticed that the zebra stripes appear on the screen between the Mobinnova and the 3D desktop startup. [I have Firefox faststart disabled on mine, so no Firefox code is involved in that.]
Comment 10 User image nicksu 2009-11-01 17:25:19 PST
Hi Justin,
I've fixed this bug (zebra stripes appear
on the screen between the Mobinnova and the 3D desktop startup ).

But I am not sure if my solution is a good way, i think maybe it's a just a temp solution.
I just let my application sleep 300 ms at start to prevent it draw screen and the system
draw screen at the same time.
Because my application also put in \Startup\ folder.(maybe firefoxfaststart is also the same situation)
I'll check with nvidia why I cannot draw my screen without delay.
Comment 11 User image Justin Dolske [:Dolske] 2009-11-05 11:34:48 PST
Created attachment 410568 [details]

Grabbed this while stepping through things in the debugger.

The nutshell version is that we're doing initial layout of the window contents at the normal (non-maximized) window size -- ideally we should notice that the persisted sizemode==maximized and use that size. I see the actual window first come up via nsXULWindow::OnChromeLoaded maximized, and when we first fill in the contents we get what's in this screenshot. Note, specifically, that the non-garbage area contains non-maximized browser chrome (I verified that its size matches the persisted width/height values).

I think the garbage is still definitely caused by something in the OS / video driver, since that bit is a regression, but if we fix this resizing issue it should wallpaper over that issue, and is probably a Ts win as well.
Comment 12 User image Justin Dolske [:Dolske] 2009-11-05 11:43:30 PST
Natch/NeilAway - any suggestions here? Enn noted you've been looking at some related stuff in bug 523909.

I did try a hacky fix of setting specWidth / specHeight in nsXULWindow::LoadSizeFromXUL() to the values they should be when maximized (instead of the persisted non-maximized width/height they normally get here). That seemed to work.
Comment 13 User image 2009-11-05 12:07:14 PST
(In reply to comment #12)
> Natch/NeilAway - any suggestions here? Enn noted you've been looking at some
> related stuff in bug 523909.
That bug is really only cleanup after fixing the case where the width and height were specified in the call; the behaviour in the typical case of persisted width and height shouldn't(!) have changed.
Comment 14 User image Nochum Sossonko [:Natch] 2009-11-05 20:54:07 PST
I _would_ suggest calling SetSize (or if it's js, set some width/height features in the open/openDialog call) from the outset, that will prevent the maximizing, but you'll lose the persisted values. Other then that unsuseful information, what neil said...
Comment 15 User image nicksu 2009-11-12 00:34:49 PST
Hi Justin,
I've tested firefox on NV new base 9.7.7
The B&W stripe part become black again.
I think NV has fixed this bug.
Comment 16 User image Justin Dolske [:Dolske] 2009-11-19 20:53:15 PST
Hmm, setting the size here looks like it will be a problem... GetBounds thinks the window is 1x1 (and GetClientBounds thinks it's 0x0). So I'm not sure how to get the desired size for a maximized window at this point. Maybe fudging it by looking at the screen size and subtracting for window styling (yuck)?
Comment 17 User image Justin Dolske [:Dolske] 2009-11-19 20:56:50 PST
Enn said he could take a look at some point, so I'll bounce this over to him. NVidia fixed the garbage issue, so this isn't a priority for 1.9.2, but it would still be good to fix since the extra reflow to the maximized size is a perf issue.
Comment 18 User image Ed Morley [:emorley] 2011-04-19 04:13:14 PDT
WinCE/Windows Mobile support has been removed from the main build system, Spidermonkey, mobile installer, in-app updater and so on (see bug 614720, bug 554087 and all their dependants). Until such point where MS decide to release a Windows Phone 7 NDK and the decision is made to port to that platform, this is WONTFIX.

Filter bugmail on WinCEMassWONTFIX.

Note You need to log in before you can comment on or make changes to this bug.