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 18.104.22.168; .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.
Steps to Reproduce:
Should not display garbage
Created attachment 407215 [details]
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...
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?
I suspect that's a side effect of bug 504499.
I didn't see the garbage on the 9/24 OS build, but I do with the 10/16 build.
We also check in our device, old version didn't have this bug.
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.
Thanks, let us know what you find.
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.]
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.
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.
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.
(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 window.open call; the behaviour in the typical case of persisted width and height shouldn't(!) have changed.
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...
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.
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)?
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.
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.