Closed Bug 887020 Opened 8 years ago Closed 8 years ago
Currently there are just 2 browser_toolbar.xml's. They are <include> in gecko_app.xml and the views are found in BrowserToolbar.from(). Also, we don't re-inflate BrowserToolbar anymore. We can make BrowserToolbar the layout instead of it having an mLayout internally. (Oh! We had this in October 2011).
First pass of BrowserToolbar cleanup. This removes BrowserToolbarLayout and moved the code to BrowserToolbar. BrowserToolbar is created directly by inflating from XML. Hence it's findViewById() happen automagically and it doesnt need a mLayout anymore. I'm still looking into moving findViewById()'s to onAttachedToWindow() as I've moved the listeners. I just want to find a remote case where we get a message from Gecko and we haven't initialized mBack yet, that could cause an NPE. If I'm sure that we won't run into that, I'll post a patch to move the findViewById() to onAttachedToWindow(). Until then this patch works fine (and just the same as what's there now).
Attachment #767480 - Flags: review?(mark.finkle)
Thinking aloud: The app takes ~700ms to display. The time between inflation and attaching to window is very very less, that our Gecko wouldn't be ready to give messages. It's safe to move all the findViewByIds() to onAttachedToWindow(). I'll move them.
(In reply to Sriram Ramasubramanian [:sriram] from comment #2) > Thinking aloud: > The app takes ~700ms to display. The time between inflation and attaching to > window is very very less, that our Gecko wouldn't be ready to give messages. > It's safe to move all the findViewByIds() to onAttachedToWindow(). I'll move > them. Don't count on Gecko always loading slowly.
Attachment #767480 - Flags: review?(mark.finkle) → review+
Assignee: nobody → sriram
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 25
You need to log in before you can comment on or make changes to this bug.