Closed Bug 849322 Opened 11 years ago Closed 11 years ago

Story - Moving Firefox Start into a <browser>

Categories

(Firefox for Metro Graveyard :: Browser, defect, P2)

x86
Windows 8.1
defect

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?
Blocks: 831920
Blocks: 849331
The decision made on Bug 849322 impacts the direction we take on Bug 849331.
Flags: needinfo?(asa)
The current perf is pretty awful. I think we need to do this.
Flags: needinfo?(asa)
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
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?
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.
Hardware: x86_64 → x86
Whiteboard: feature=story c=tbd u=tbd p=0 → feature=story c=firefox_start u=metro_firefox_user p=0
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?
That was a quote from jimm I'll let him comment here sine he's the expert in the OMTC area :D
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Whiteboard: feature=story c=firefox_start u=metro_firefox_user p=0
No longer blocks: metrov1onhold
No longer blocks: 831920, 849331
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.