Closed Bug 886605 Opened 11 years ago Closed 6 years ago

Google Ads will open in target _top window

Categories

(Firefox OS Graveyard :: Gaia::System, defect, P3)

Product:
Firefox OS Graveyard
Component:
Gaia::System
Platform:
x86
macOS
Type:
defect

Tracking

(tracking-b2g:backlog)

Status:
RESOLVED WONTFIX
Project Flags:
tracking-b2g backlog

People

(Reporter: lstowasser, Assigned: fabrice)

References

Details

(Whiteboard: [sitewait], [systemsfe], [apps watch list]) 

A requirement for apps submitted to the marketplace is that links to external websites open in a new browser window (as there is no back button), including ads.

This becomes a problem with Google adsense ads as they are contained in an IFrame and all links open with target `_top`. Due to cross-domain restrictions there is no way to force the links to open with target `_blank`. 

This affects any partner with Google Ads including 8tracks.
Note - Before doing this, you would need to solve bug 812154. Right now, getting Google Ads served to a Firefox OS user agent renders an empty HTML document.
Component: Gaia → General
Blocks: 880794
Depends on: 812154
This bug is likely to resurface at some point with another company. Perhaps we should proceed with a solution that addresses this issue in our platform such as treating the _top target in any link that exists in content that originates from outside of the app's origin as a _blank target.

Jonas - Thoughts?
Also want to note that BD has recently run into this issue with:

-Merriam-Webster Dictionary
-PennySaverUSA
(In reply to Silvio Chiba from comment #3)
> Also want to note that BD has recently run into this issue with:
> 
> -Merriam-Webster Dictionary
> -PennySaverUSA

Silvio,
What do you mean by BD? and what about the list of these two names? Are there Web sites? or something else? :)
Flags: needinfo?(schiba)
Hey Karl,

Business Development for FFOS Content Acquisition 

The two names are apps in the form of mobile sites that were recently rejected due to the Google adsense issue Louis described above.
Flags: needinfo?(schiba)
- 8tracks
- theCHIVE (ads served from Mopub)

have this issue too.  We're very keen on getting these partners listed but as of right now we're not able to due to this platform bug.

To that end do we have an ETA of when a fix for this issue will land?
Karl - Any response from Google on this issue?
Flags: needinfo?(kdubost)
I recontacted our contact at Google.
Flags: needinfo?(kdubost)
Great - let us know what you hear back.
Whiteboard: [sitewait]
I'd rather not do the solution in comment 2 as there seems like legitimate cases where you want such links to open in-browser.

However we have discussed adding the ability to in the manifest enumerate the set of domains/origins that should open within the app. Anything top-level navigation to outside that set would automatically be opened in the browser.

We punted on that due to time constraints, but maybe it's time to implement something like that now.
(In reply to Jonas Sicking (:sicking) from comment #10)
> I'd rather not do the solution in comment 2 as there seems like legitimate
> cases where you want such links to open in-browser.
> 
> However we have discussed adding the ability to in the manifest enumerate
> the set of domains/origins that should open within the app. Anything
> top-level navigation to outside that set would automatically be opened in
> the browser.
> 
> We punted on that due to time constraints, but maybe it's time to implement
> something like that now.

I think this is a good idea as I doubt that Google ads will be the only case that we encounter with links targeting _top. It will be somewhat of a failure on our part if we require companies to special case Firefox OS in their products.
Do we know how is it implemented across the board (Opera (Mobile/Mini), Safari, Chrome, UCWeb, etc.)?
From the Google support docs, Adsense doesn't seem to have any special cases per runtime, only per country.

Phonegap and other webapp wrappers force external links to open in the system browser via system level hooks into link handling.

This solution was implemented while prototyping webapps back in the labs days (but didn't make it into any runtime). Webapp manifests could whitelist origins, so the runtime could cleanly forward external links to the browser.
blocking-b2g: --- → koi?
Component: General → Gaia::System
Brad - What's the koi? nomination for?

We're really late in the release right now, so it's going to be tough to take anything other than regressions or critical 1.2 specific issues.
Flags: needinfo?(blassey.bugs)
(In reply to Jason Smith [:jsmith] from comment #14)
> Brad - What's the koi? nomination for?
> 
> We're really late in the release right now, so it's going to be tough to
> take anything other than regressions or critical 1.2 specific issues.

consensus from the web compat team was that this bug is particularly bad and should be on the radar for drivers. If it can't make 1.2, that's their call.
Flags: needinfo?(blassey.bugs)
It is quite late to be taking this in 1.2.  
If we wouldn't block the whole release on this, then I suggest we take it into our backlog.
Gregor, any idea if we can get this done in 1.3?
blocking-b2g: koi? → -
Flags: needinfo?(anygregor)
Whiteboard: [sitewait] → [sitewait],[1.3:P2, systemsfe]
I assume it will be a non trivial amount of work if we do what Jonas suggests in comment 10.
With all our other target deliveries for 1.3 I don't think we can add it without removing something else.
Flags: needinfo?(anygregor)
(In reply to Gregor Wagner [:gwagner] from comment #17)
> I assume it will be a non trivial amount of work if we do what Jonas
> suggests in comment 10.
> With all our other target deliveries for 1.3 I don't think we can add it
> without removing something else.

Right - I think we should just keep this generically on the backlog for now and evaluate this for a future release in alignment with other priorities. I'm pulling the 1.3:P2 flag as such.
Whiteboard: [sitewait],[1.3:P2, systemsfe] → [sitewait], [systemsfe]
To be clear, this bug impacts app monetization on Firefox OS. While I'm not advocating that this be fixed in 1.3 specifically, I would like to see this on the roadmap with a specific target. I'm going to nom for 1.4 so that it's at least on the radar.
blocking-b2g: - → 1.4?
blocking-b2g: 1.4? → ---
nom cleared without justification. As I no longer see the 1.4? option for blocking-b2g, I have flagged as madai? in the hope that is correct.
blocking-b2g: --- → madai?
Assignee: nobody → fabrice
Fabrice, what is your plan here? I'm hoping to that something like what's described in comment 10 can be added to the standard manifest that Marcos is working on so it'd be great to do an initial experiment here.
From working with partners I can say that a whitelist would solve reoccurring problems for the manifest to control link targets by their origin.

The same whitelist pattern could be applied to get rid of systemXHR for many cases and limit external network access with a whitelist declared the manifest. Blackberry has a similar model [1].

[1]: http://developer.blackberry.com/html5/documentation/beta/access_element.html
The systemXHR issue has different security implications, so lets debate that elsewhere. Please open a new bug or send an email to dev-webapi.
But definitely very useful to know that partners could benefit from a navigation whitelist! Could you help getting some of them to test out early builds to make sure that it satisfies the use cases?
(In reply to Jonas Sicking (:sicking) needinfo? or feedback? encouraged. from comment #21)
> Fabrice, what is your plan here? I'm hoping to that something like what's
> described in comment 10 can be added to the standard manifest that Marcos is
> working on so it'd be great to do an initial experiment here.

The plan is to implement comment #10. I won't give a time estimate though, since someone pointed me recently to a comment I made 5 month ago stating that I'll fix something 'in a week' ;)

What do we want to do in the default case where no whitelist is provided in the manifest? Open every link inside the app? Or consider that we use the app origin/domain for hosted apps as a default whitelist?
I didn't mean to ask for a time estimate. I was more thinking that we should ensure that Marcos is paying attention here so that if he has input he can provide it. And so that whatever we learn from our implementation goes into making the spec better once we do spec this.

I think that the default policy needs to be to open anything inside the app unfortunately. It's not great, but I don't see any options.

There's also the question of what the whitelist pattern should look like. Just origins? Origins and domains? Origins, domains and domain-patterns (i.e. *.tumblr.com)?
For the specific case of Google AdSense you can contact their support and ask to enable new window targeting for all your ads. This has been working fine for me. (Though I'm stuck now with a different problem.)
Whiteboard: [sitewait], [systemsfe] → [sitewait], [systemsfe], [apps watch list]
retiring the madai flag, setting 1.5? but feel free to adjust as you see fit.
blocking-b2g: madai? → 1.5?
This is a feature request, which should not be tracked under the blocking b2g flag.
blocking-b2g: 2.0? → backlog
Priority: -- → P3
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
Does this still make sense today?
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.