Closed
Bug 469412
Opened 16 years ago
Closed 16 years ago
remove native widgets from xul decks
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
FIXED
People
(Reporter: blassey, Assigned: blassey)
Details
(Keywords: fixed1.9.1, mobile)
Attachments
(3 files, 1 obsolete file)
1.31 KB,
patch
|
Details | Diff | Splinter Review | |
6.15 KB,
image/png
|
Details | |
995 bytes,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
Deck elements have been a significant performance problem for mobile, presumably because they create native widgets.
Attachment #352798 -
Flags: review?(bzbarsky)
Assignee | ||
Updated•16 years ago
|
Attachment #352798 -
Flags: review?(roc)
Assignee | ||
Comment 1•16 years ago
|
||
Assignee | ||
Comment 2•16 years ago
|
||
Comment 3•16 years ago
|
||
I assume you tested things like iframes in decks? And trees in decks? Trees in decks are why that code is there in the first place (see bug 43206). I'm not quite sure what the test attached here is testing, fwiw.
Some people use decks to work around bug 130078. Changing this would break them.
For that reason I think I'd prefer it if we turned off widgets based on checking some attribute of the <deck>, say <deck lightweight="true">.
Assignee | ||
Comment 6•16 years ago
|
||
(In reply to comment #5) > For that reason I think I'd prefer it if we turned off widgets based on > checking some attribute of the <deck>, say <deck lightweight="true">. One thing that concerns me is an extension introducing a major performance problem by inadvertently. If there was a flag, it might be better for it to be <deck forcenative="true"/> Do you have an example of where someone is using this work around?
Comment 7•16 years ago
|
||
(In reply to comment #6) > One thing that concerns me is an extension introducing a major performance > problem by inadvertently. If there was a flag, it might be better for it to be > <deck forcenative="true"/> That wouldn't be backwards compatible. If mobile wants all decks to not use widgets then maybe a preference or build-time option would be better. Essentially we don't want to have to have developers think about this kind of low-level thing, especially when we want to remove these widgets anyway.
(In reply to comment #6) > (In reply to comment #5) > > For that reason I think I'd prefer it if we turned off widgets based on > > checking some attribute of the <deck>, say <deck lightweight="true">. > > One thing that concerns me is an extension introducing a major performance > problem by inadvertently. If there was a flag, it might be better for it to be > <deck forcenative="true"/> > > Do you have an example of where someone is using this work around? I don't have an example at hand, but I know that this work-around has been recommended to people in the past. The safe thing to do here is to be backwards compatible. If we want to use a pref to switch this behaviour for mobile, that's OK with me. I could even accept an #ifdef, since I expect to be getting rid of these widgets anyway.
Assignee | ||
Comment 9•16 years ago
|
||
Assignee: nobody → bugmail
Attachment #352798 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #353580 -
Flags: review?(roc)
Attachment #352798 -
Flags: review?(roc)
Attachment #352798 -
Flags: review?(bzbarsky)
Attachment #353580 -
Flags: superreview+
Attachment #353580 -
Flags: review?(roc)
Attachment #353580 -
Flags: review+
Comment 10•16 years ago
|
||
Perhaps MOZ_GFX_OPTIMIZE_MOBILE should be renamed to MOZ_OPTIMIZE_MOBILE if it's going to be used outside of gfx.
Assignee | ||
Comment 11•16 years ago
|
||
changeset: 23178:aed3c0bdeb72 tag: qparent user: Brad Lassey <blassey@mozilla.com> date: Mon Dec 29 12:00:12 2008 -0500 summary: bug 469412 - remove native widgets from xul decks, mobile only r+sr=roc
Assignee | ||
Updated•16 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 12•15 years ago
|
||
pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/45db3a2e209f
Assignee | ||
Updated•15 years ago
|
Keywords: fixed1.9.1
You need to log in
before you can comment on or make changes to this bug.
Description
•