The default bug view has changed. See this FAQ.

Fennec Layout is broken on initial startup after landing bug 688505

VERIFIED FIXED in Firefox 9

Status

Fennec Graveyard
General
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: romaxa, Assigned: romaxa)

Tracking

({regression})

Trunk
Firefox 9
ARM
Maemo
regression
Bug Flags:
in-testsuite -

Details

(Whiteboard: [fixed in aurora])

Attachments

(3 attachments, 4 obsolete attachments)

(Assignee)

Description

6 years ago
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 <wjohnston@mozilla.com>
date:        Thu Sep 22 17:04:15 2011 -0700
summary:     Bug 688505 - Use keyhole shape for back button on Honeycomb. r=mfinkle
(Assignee)

Updated

6 years ago
Keywords: regression
Is this the same layout issue as in bug 689928 ?
(Assignee)

Comment 2

6 years ago
Found that removing svg:svg entry from browser.xul fixes the problem...
is it android only?
(Assignee)

Comment 3

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

Comment 5

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

Comment 7

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

Comment 8

6 years ago
Created attachment 564570 [details]
Photo of broken layout1
(Assignee)

Comment 9

6 years ago
Created attachment 564571 [details]
Photo of broken layout 2
Comment on attachment 564559 [details] [diff] [review]
Possible patch

This probably kills the SVG altogether
Attachment #564559 - Flags: review?(mark.finkle) → review-
(Assignee)

Comment 11

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

Comment 12

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

Comment 15

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

Comment 16

6 years ago
Created attachment 564699 [details]
resize log before and after
(Assignee)

Comment 17

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

Comment 18

6 years ago
Created attachment 565132 [details] [diff] [review]
Call first resize by timeout in case if native View already resized

Make it MAEMO only
Attachment #564699 - Attachment is obsolete: true
Attachment #564733 - Attachment is obsolete: true
Attachment #564733 - Flags: review?(mark.finkle)
Attachment #565132 - Flags: review?(mark.finkle)
(Assignee)

Comment 19

6 years ago
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.
Attachment #565132 - Attachment is obsolete: true
Attachment #565132 - Flags: review?(mark.finkle)
Attachment #565337 - Flags: review?(mbrubeck)
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+
(Assignee)

Updated

6 years ago
Keywords: checkin-needed
(Assignee)

Updated

6 years ago
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?

Updated

6 years ago
Attachment #565337 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/integration/mozilla-inbound/rev/22f7450fdc4b
Flags: in-testsuite-
Keywords: checkin-needed
Target Milestone: --- → Firefox 10
status-firefox10: --- → fixed
status-firefox9: --- → affected
https://hg.mozilla.org/releases/mozilla-aurora/rev/327b44552e6f
status-firefox9: affected → fixed
Whiteboard: [fixed in aurora]
Target Milestone: Firefox 10 → Firefox 9
https://hg.mozilla.org/mozilla-central/rev/22f7450fdc4b
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 25

6 years ago
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.