Closed
Bug 1184953
Opened 10 years ago
Closed 7 years ago
[Web Components] Document's element registry is not persisted in the BF Cache
Categories
(Firefox OS Graveyard :: Gaia, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: borjasalguero, Unassigned)
References
Details
(Whiteboard: [NG Gaia Contacts])
In NGA, we will have some panels loaded in a separate .html, and others loaded within the same index.html.
When testing this in Contacts [1], we have reproduce this in [2] following the STR:
- Open Contacts App and create a contact 'EXAMPLE'.
- Close the app.
- Open the app, and tap on 'EXAMPLE'. Tap on 'edit' (with this we are changing the location 2 times)
- Go back until reaching the list of contacts
- Tap on 'Settings'
EXPECTED:
Settings is shown as expected
CURRENTLY:
All header & subheader styles are not available, and the UI is broken
This is needed due to NGA is based on this, and we could block the development of it.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1183727
[2] https://github.com/mozilla-b2g/gaia/pull/30983
Updated•10 years ago
|
Whiteboard: [NG Gaia Contacts]
| Reporter | ||
Comment 1•10 years ago
|
||
Wilson, I think you found a set of steps to reproduce this. Could you add a comment explaining the issue? Thanks!
Flags: needinfo?(wilsonpage)
Comment 2•10 years ago
|
||
I've created a test-case the proves that custom-element registrations are not persisted in the BF Cache.
https://wilsonpage.github.io/custom-elements/bf-cache/
1. Navigate to a.html that runs `document.registerElement('x-foo', ...)`
2. Navigate to b.html
3. `history.back()`
4. `document.createElement('x-foo')`
EXPECTED: An instance of the initially registered 'x-foo' should be created
ACTUAL: 'x-foo' is not registered and behaves the same as running `document.createElement('x-bar')`
Flags: needinfo?(wilsonpage)
Updated•10 years ago
|
Flags: needinfo?(wchen)
Flags: needinfo?(bugs)
Summary: [Web Components] When using gaia-header in an app with multiple views sometimes styles are not loaded. → [Web Components] Document's element registry is not persisted in the BF Cache
Comment 3•10 years ago
|
||
I'm not really familiar with registerElement handling.
wchen and perhaps also gabor know this stuff.
Flags: needinfo?(bugs)
Updated•10 years ago
|
Flags: needinfo?(gkrizsanits)
Comment 4•10 years ago
|
||
I don't really have the time right now to work on this. But it seems like a bug to me. I think we create a new registry here http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDocument.cpp#4730 even if we're just coming out of the bf cache. I wouldn't know what's the proper way to fix it but I'm sure William can figure this out when he has some free cycles for it.
Flags: needinfo?(gkrizsanits)
Comment 5•10 years ago
|
||
William told me his impression is that this isn't super high priority and that this is "just something that needs to be done" (and he may have an old patch).
Flags: needinfo?(wchen)
Comment 6•7 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•