Closed
Bug 523291
Opened 15 years ago
Closed 14 years ago
Chrome initially sized wrong when restoring a maximized window
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: starking, Unassigned)
Details
(Whiteboard: [nv])
Attachments
(2 files)
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 2.0.4.16; .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
Updated•15 years ago
|
OS: Other → Windows CE
Hardware: Other → ARM
Summary: Launch firefox will display garbage in a short time → [WinCE] After launching firefox will display garbage in a short time
Whiteboard: [nv]
Version: unspecified → 3.6 Branch
Comment 2•15 years ago
|
||
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...
Thanks,
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•15 years ago
|
||
I suspect that's a side effect of bug 504499.
Comment 5•15 years ago
|
||
I didn't see the garbage on the 9/24 OS build, but I do with the 10/16 build.
Assignee: nobody → dolske
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
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.
Comment 8•15 years ago
|
||
Thanks, let us know what you find.
Comment 9•15 years ago
|
||
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.]
Reporter | ||
Comment 10•15 years ago
|
||
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.
Updated•15 years ago
|
Summary: [WinCE] After launching firefox will display garbage in a short time → [WinCE] After launching firefox will display screen garbage in a short time
Comment 11•15 years ago
|
||
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.
Updated•15 years ago
|
Component: General → XUL
Product: Firefox → Core
QA Contact: general → xptoolkit.widgets
Version: 3.6 Branch → 1.9.2 Branch
Comment 12•15 years ago
|
||
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•15 years ago
|
||
(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.
Comment 14•15 years ago
|
||
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...
Reporter | ||
Comment 15•15 years ago
|
||
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.
Thanks.
Comment 16•15 years ago
|
||
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•15 years ago
|
||
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.
Assignee: dolske → enndeakin
Priority: P1 → --
Summary: [WinCE] After launching firefox will display screen garbage in a short time → Chrome initially sized wrong when restoring a maximized window
Updated•14 years ago
|
Assignee: enndeakin → nobody
Comment 18•14 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•