On first startup fennec layout looks broken, side/tool bars overlapping each other. rotation/resize is needed in order to restore normal behavior after bisecting I've found changeset: 77851:3e60b13624dc user: Wes Johnston <email@example.com> date: Thu Sep 22 17:04:15 2011 -0700 summary: Bug 688505 - Use keyhole shape for back button on Honeycomb. r=mfinkle
Is this the same layout issue as in bug 689928 ?
Found that removing svg:svg entry from browser.xul fixes the problem... is it android only?
No it is different, I see right side bar about in the middle of screen, or even sometimes right after left sidebar
Got a screenshot of the problem? What device?
Created attachment 564559 [details] [diff] [review] Possible patch I've changed svg:svg -> just svg, and it started working fine
Attachment #564559 - Flags: review?(mark.finkle)
I don't see the aforementioned abnormalities on 10/04 (SII) and 10/04 (Tab 10.1).
(In reply to Mark Finkle (:mfinkle) from comment #1) > Is this the same layout issue as in bug 689928 ? it could be in case if initial startup on android having more main window resizes than in Maemo...
Comment on attachment 564559 [details] [diff] [review] Possible patch This probably kills the SVG altogether
Attachment #564559 - Flags: review?(mark.finkle) → review-
I've noticed one more thing, if I start fennec without any url command, then broken layout only visible in the beginning and then replaced with FF home page.. but if I start fennec with some url in command line like, ./fennec http://google.com - then layout is broken and stays broken until resize happen.
> This probably kills the SVG altogether why that kills SVG? I see svg still working even with that patch, at least element created and no parsing errors visible
Comment on attachment 564559 [details] [diff] [review] Possible patch OK. Pushing to Wes so he can test that this does not break what he did in the original bug.
Attachment #564559 - Flags: review- → review?(wjohnston)
Comment on attachment 564559 [details] [diff] [review] Possible patch Review of attachment 564559 [details] [diff] [review]: ----------------------------------------------------------------- This is invalid markup and breaks the mask in our Honeycomb theme (i.e. try highlighting the forward button).
Attachment #564559 - Flags: review?(wjohnston) → review-
Checked more deeply resizeHandler calls, and found that before that fix we have 5 nsWindow::OnResizeEvent events, and that triggering fennec resizeHandler... after that fix we have only 3 nsWindow::OnResizeEvent calls and fennec resizeHandler never triggered
Created attachment 564733 [details] [diff] [review] Call first resize by timeout in case if native View already resized ok, we do call DispatchResizeEvent in nsWindow after resizeHandler registered, but it does not reach PresShell::ResizeReflow, because size is the same and it is blocked in nsViewManager::DoSetWindowDimensions. so currently we don't see this problem on android because native widget is not sized properly before fennec register resizeHandler.
Assignee: nobody → romaxa
Status: NEW → ASSIGNED
Attachment #564733 - Flags: review?(mark.finkle)
Created attachment 565132 [details] [diff] [review] Call first resize by timeout in case if native View already resized Make it MAEMO only
Created attachment 565337 [details] [diff] [review] Don't specify xulwindow size if fullscreen size specified Ok, I've found real problem which is causing wrong resize event 480,480 during startup. even if widget sized properly after initial startup, we still get event before startup with bad size, which is coming from nsXULWindow::LoadSizeFromXUL, that code calculating spec size based on xul window params, and ignoring fullscreen definition... Here is the simple fix which does not specify width, height for maemo, because fullscreen size mode already specified.
Comment on attachment 565337 [details] [diff] [review] Don't specify xulwindow size if fullscreen size specified I wonder whether we should get rid of these on Android too.
Attachment #565337 - Flags: review?(mbrubeck) → review+
Attachment #564559 - Attachment is obsolete: true
Comment on attachment 565337 [details] [diff] [review] Don't specify xulwindow size if fullscreen size specified Requesting mozilla-approval-aurora for Firefox 9, at romaxa's request. This fixes a Maemo-only regression that breaks the community-maintained Maemo port of Fennec. The fix is also Maemo-only; it does not change a single line of code for other platforms. It just eliminates (on Maemo) hard-coded sizes in our XUL.
Attachment #565337 - Flags: approval-mozilla-aurora?
Attachment #565337 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Target Milestone: --- → Firefox 10
status-firefox10: --- → fixed
status-firefox9: --- → affected
status-firefox9: affected → fixed
Whiteboard: [fixed in aurora]
Target Milestone: Firefox 10 → Firefox 9
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Build ID: Mozilla/5.0 (Maemo; Linux armv7l; rv:9.0a2) Gecko/20111019 Firefox/9.0a2 Fennec/9.0a2 Device: Nokia N900 - Maemo 5 Issue was verified on above environment on landscape and portrait, with FF start page and also starting fennec with some url in command line like: "fennec http://google.com" - Fennc layout was not broken.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.