Closed Bug 1184953 Opened 4 years ago Closed 2 years ago

[Web Components] Document's element registry is not persisted in the BF Cache

Categories

(Firefox OS Graveyard :: Gaia, defect)

ARM
Gonk (Firefox OS)
defect
Not set

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
Blocks: 1183727
Whiteboard: [NG Gaia Contacts]
Wilson, I think you found a set of steps to reproduce this. Could you add a comment explaining the issue? Thanks!
Flags: needinfo?(wilsonpage)
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)
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
I'm not really familiar with registerElement handling.
wchen and perhaps also gabor know this stuff.
Flags: needinfo?(bugs)
Flags: needinfo?(gkrizsanits)
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)
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)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.