Closed Bug 1184953 Opened 4 years ago Closed 2 years ago
[Web Components] Document's element registry is not persisted in the BF Cache
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 , we have reproduce this in  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.  https://bugzilla.mozilla.org/show_bug.cgi?id=1183727  https://github.com/mozilla-b2g/gaia/pull/30983
Wilson, I think you found a set of steps to reproduce this. Could you add a comment explaining the issue? Thanks!
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')`
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.
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.
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).
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.