1014501 - [WebComponents] style import polyfill

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Description

[Wilson Page [:wilsonpage]]

There is currently a bug in platform that inconsistently renders styling when @import statements are used inside shadow-dom templates. Styling does work correctly when directly inlined in the template.

If we can incorporate CSS inlining into custom-element templates then we can work around this platform bug and implement web-components in Gaia sooner.

This build step will reduce requests at app runtime, so we may choose to keep it around even when the platform is fixed (needs discussion).

Comment 1

[Wilson Page [:wilsonpage]]

Platform bug 1003294

Comment 2

[Kevin Grandon :kgrandon]

I might take a look at this later, but I would love it if someone wants to free me from the pain that this will be :)

Comment 3

[Kevin Grandon :kgrandon]

Attachment: Work in progress

Comment 4

[Kevin Grandon :kgrandon]

Attachment: Github pull request

Comment 5

[Kevin Grandon :kgrandon]

Comment on attachment 8428178 [details] [review]
Github pull request

Here is an alternate pull request which requires the inclusion of shared/js/component_utils.js for the time being. I think this is an acceptable approach for now, and I can file a bug to inline this automatically at build step if desired. 

I have a patch that can inline this file everywhere, but the build system is currently undergoing refactoring and a backout there just obsoleted my patch =/

Wilson, Yan - what do you guys think?

Comment 6

[Yan Or]

Comment on attachment 8428178 [details] [review]
Github pull request

Looks good.

Comment 7

[Yan Or]

Attachment: Screen Shot 2014-05-24 at 2.32.09 PM.png

It doesn't seem to resolve bug 1003294 though.  While the demo page works fine, if I put the demo page inside gaia (disguised as wallpaper/pick.html), the rendering is still inconsistent.

Comment 8

[Kevin Grandon :kgrandon]

Hmm, ok. Let me verify again and maybe try another approach. I tested and was not able to reproduce, but I only tested with a single component, not all of the examples.

Comment 9

[Kevin Grandon :kgrandon]

(In reply to Yan Or from comment #7)
> Created attachment 8428326 [details]
> Screen Shot 2014-05-24 at 2.32.09 PM.png
> 
> It doesn't seem to resolve bug 1003294 though.  While the demo page works
> fine, if I put the demo page inside gaia (disguised as wallpaper/pick.html),
> the rendering is still inconsistent.

Yan - can you provide the exact content of your test page?

I tested this patch on a device, and could not reproduce. I am fairly confident that this resolves the issue, so I am going to land in master for now so Wilson/Aranau can test it as well. (If there's any reason it doesn't work I'll gladly back it out).

I'm also thinking we should write a simple test app which embeds all of the examples so we all have some simple test pages to use.

Landed: https://github.com/mozilla-b2g/gaia/commit/f5b559ff148709c689f2f38e46a47dff1e14c42b

Comment 10

[Kevin Grandon :kgrandon]

Attachment: Test page

Yan - here is the test page that I used that should work with the latest master. Could you compare it to yours and try it to see if it works for you? Thanks!

Comment 11

[Yan Or]

Kevin, still seeing the problem.  Here are the steps I did:

1. Get the latest master
2. Create a file "gaia-header-demo.html" with your test page contents under apps/wallpapers
3. DEBUG=1 make
4. Run firefox nightly (latest) with the debug profile and -no-remote
5. Open http://wallpaper.gaiamobile.org:8080/gaia-header-demo.html
6. Still seeing inconsistent rendering - refresh will render random headers correctly

I have not tried on a device.  Should I not use firefox nightly?  I find it easier to debug.

Comment 12

[Kevin Grandon :kgrandon]

Ok, I will do some verification in Firefox Nightly this week. It's something we should support, but solving this on a device is the most important thing (so we can actually use it this release).

Comment 13

[Yan Or]

I ran one of the ported app (Wallpaper) on a device with the latest master and cannot constantly reproduce the problem.  It happened the first time but then rendered correctly afterward - rebooting the device could not repeat the first time error.

Will report back if I see it on a more complicated app.

Comment 14

[Wilson Page [:wilsonpage]]

gmarty tried a variation of this fix in his gaia-header work and said that it worked on desktop, but not on device.

Comment 15

[Kevin Grandon :kgrandon]

Please send me a test page that is not working for you on a device and I will take a look. Thanks!

Comment 16

[Yan Or]

Kevin,

I ran into a possibly related problem when porting the browser app.  Here's the PR:

https://github.com/mozilla-b2g/gaia/pull/19700

The "Settings" header doesn't show up with this.  The slight difference here is that the HTML block is delay loaded.  However, the same case works with fine with the "Edit Bookmark" header.

Comment 17

[Kevin Grandon :kgrandon]

Hmm, ok. Perhaps there is some problem when using a "delayed" load. ni? on myself to take another look.

Comment 18

[Kevin Grandon :kgrandon]

Appears that pull request is outdated and has merge conflicts. I'll check again once it's been rebased.

In the meantime I will try reproducing locally, and if you have a small isolated testcase I will take a look again.

Comment 19

[Yan Or]

Ok, rebased.  Try now.

Comment 20

[Kevin Grandon :kgrandon]

Right - that sounds like bug 1007743 which was not a goal of this bug. That bug has a patch, so we can see if we can land it in the next few days. If we can't, I can work on a workaround for that bug as well.