918004 - B2G: Can't see remote stylesheets in Style Editor

Status: RESOLVED FIXED

(DevTools Graveyard :: WebIDE, defect, P1)

Description

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

While debugging bug 917306, I noticed that currently the Style Editor can't display remote stylesheets inside B2G apps.

When the actor attempts to run _loadSourceFromCache for a remote (http[s]) stylesheet, asyncOpen on the channel fails.  

My current suspicion for why this happens is that for B2G apps, the actor code is loaded into the same context as the app itself, and so the B2G security model is blocking the actor from making this request, just as it would for some types of apps.

I have seen this issue in at least two apps so far:

* Marketplace app (app://marketplace.firefox.com/index.html)
 * 1 app:// sheet (this usually loads, but see bug 917306)
 * <iframe src="https://marketplace.firefox.com/?mcc=&mnc="></iframe>
   * 2 https:// sheets inside (these fail to load)
* Twitter app (sign in page) (https://mobile.twitter.com/)
 * 1 inline sheet (loads fine)
 * 1 https:// sheet directly on page (this fails to load)

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Attachment: Workaround

Here's my workaround to show the remote sheets.  Seems bad, since I assume |setPrivate| needs to stay there... :)

Comment 2

[Paul Rouget [:paul]]

Heather, can you take a quick look at this? Is there an easy way to work around that?

Comment 3

[Paul Rouget [:paul]]

(also look at bug 917306 comment 5)

Comment 4

[Alexandre Poirot [:ochameau]]

Are these iframes regular iframes with just a `src` attribute, or are they using mozbrowser and/or mozapp attribute(s)? If they don't, we should have same kind of limitations than in firefox desktop. The actor still loads in chrome sandboxes.
But mozbrowser iframes introduce security limitation that can't be bypassed by chrome priviledges.
And if they use mozapp, the iframe will run in another process...
So, if these iframes use mozbrowser API, it would be easier to implement iframe target support rather than working around b2g security model. If they don't, it sounds like there is a bug to fix.

Comment 5

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Alexandre Poirot (:ochameau) from comment #4)
> Are these iframes regular iframes with just a `src` attribute, or are they
> using mozbrowser and/or mozapp attribute(s)?

In the case of the Marketplace app, it is just a regular iframe with a src.

For the Twitter app, there is no iframe involved, but the app itself is a hosted app, not a packaged app on the device.

Comment 6

[Paul Rouget [:paul]]

http://bugmotodo.org has the same problem.

Comment 7

[Paul Rouget [:paul]]

Attachment: Patch v1

Using the same loadGroup as the window.

Comment 8

[Paul Rouget [:paul]]

jryans came up with this solution. Ehsan confirmed that might be a good-enough way to do it.

Comment 9

[Paul Rouget [:paul]]

Comment on attachment 808604 [details] [diff] [review]
Patch v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): new feature (app manager)
User impact if declined: can't correctly use the style editor with apps
Testing completed (on m-c, etc.): locally
Risk to taking this patch (and alternatives if risky): low
String or IDL/UUID changes made by this patch: none

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/fx-team/rev/fec9d73df125

Comment 11

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/fec9d73df125

Comment 12

[Paul Rouget [:paul]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a02ef3b1129f