Closed
Bug 849322
Opened 12 years ago
Closed 12 years ago
Story - Moving Firefox Start into a <browser>
Categories
(Firefox for Metro Graveyard :: Browser, defect, P2)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 850737
People
(Reporter: bbondy, Unassigned)
Details
On Fri, Mar 1, 2013 at 11:48 AM, Jim Mathies <jmathies@mozilla.com> wrote:
Working on omtc and apzc today it hit me that the chrome based Firefox Start view will completely miss out on all the work we do to make <browser> fast. Curious what people think about the idea of converting it to html? My experience thus far with ‘xulfs’ is that it suffers from perf problems when panning. This might be a design flaw in the underlying xul, or it might just be a perf limitation of xul rendering in general. We’ll want smooth pan for fs, and in time I think we might want smooth zoom as well. Hooking the apzc up to chrome will require extra time and work which we don’t have. I’d rather concentrate on improving <browser> knowing fs benefits along with content.
Porting it over doesn’t seem like it would be a big job to me, but I haven’t done much work on it. FWIU, changes would involve converting direct methods calls to Browser/BrowserUI into message manager messages. Existing test might break too.
If we want to do this but feel the current pan perf is ok for the initial train ride we could put it off to a subsequent train. However if we think we’ve hit a limitation in xul pan perf as things stand now and we know we want smooth pan and zoom down the road in fs, maybe we should consider adding this as a goal to the current v1 release?
Comment 1•12 years ago
|
||
The decision made on Bug 849322 impacts the direction we take on Bug 849331.
Flags: needinfo?(asa)
Comment 2•12 years ago
|
||
The current perf is pretty awful. I think we need to do this.
Flags: needinfo?(asa)
Updated•12 years ago
|
Blocks: metrov1onhold
Priority: -- → P2
QA Contact: jbecerra
Summary: Moving Firefox Start into a <browser> → Story - Moving Firefox Start into a <browser>
Whiteboard: feature=story c=tbd u=tbd p=0
Comment 3•12 years ago
|
||
Thanks Asa and Brian.
Asa, what component and user would you like in the whiteboard?
Brian, any particular work items that need to be dependent on this new story?
Reporter | ||
Comment 4•12 years ago
|
||
This should probably be worked on in this coming iteration if we're doing it since it blocks a ton of bugs.
> Brian, any particular work items that need to be dependent on this new story?
mbrubeck may be best to slice this up into different bugs.
Updated•12 years ago
|
Hardware: x86_64 → x86
Whiteboard: feature=story c=tbd u=tbd p=0 → feature=story c=firefox_start u=metro_firefox_user p=0
Comment 5•12 years ago
|
||
Hi Brian, in your first comment you mentioned, "Hooking the apzc up to chrome will require extra time and work which we don’t have."
Would it be worth it to do it that way/the best way to proceed?
Reporter | ||
Comment 6•12 years ago
|
||
That was a quote from jimm I'll let him comment here sine he's the expert in the OMTC area :D
Comment 7•12 years ago
|
||
This may not be the case depending on how we implement it, but until I get sign off from layout folks I won't say yes or no to anything. What I'm wondering is if we can hook an apzc up to nsIScrollableFrame or some subset of frames that implement that. That would give us apzc on all sorts of elements including the start screen. *but* I don't know yet it this will be possible.
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Whiteboard: feature=story c=firefox_start u=metro_firefox_user p=0
Updated•12 years ago
|
No longer blocks: metrov1onhold
Updated•12 years ago
|
Assignee | ||
Updated•10 years ago
|
OS: Windows 8 Metro → Windows 8.1
You need to log in
before you can comment on or make changes to this bug.
Description
•