Spotify Advertiser Page - javascript

I'm making a Spotify Advertiser page, but recently Spotify updated to version 1.0.1.1060.gc75ebdfd and now all the links with "a href" are opening in the native browser and not in the micro browser inside Spotify. I already tried using the "target='_self'" and that did not work, and as a solution I started using javascript with location.href on onClick event and that works. I need to open the page to share on Facebook and Twitter, but it wont open with JS only with "a href"
Anyone know what might be or how can it be fix?

Unfortunately, this behavior is not supported any longer. The old client (ie, all versions less than 1.0.0) was built from a combination of web and native views, and therefore the web views were less restricted in terms of what type of content they could open since such content would only live in a small frame.
The new client, however, is essentially a single webview with a native wrapper around it. This solves lots of problems (from both a UX and a technical standpoint), but it also means that there is only one browser shared by all components. If the new client supported "target='_self'", the content opened by your banner ad would take over the entire application window area -- including the back/forward buttons, search bar, etc. This is why we now force all external URLs to be opened in the system web browser instead.

Related

Is there a safe way for a web extension to have ui inside tab?

browser web extension can provide ui to interact with the user such as (sidebars sidebar_action), or little icons that allow a popup upon click browser_action).
I however would like my extension to provide a user interface being displayed directly overlaying the the web page and hence in the center of the currently open tab. Right inside the tab. In order to display anything inside the tab I have though of using a content-script and modify the web pages DOM, but it seems to me that this is not a safe method, as it would open up a possibilty for the untrusted web page's code to impact the UI (e.g. it could just delete the UI created, or worse modify it, hence interact maliciously in the communication between my content-script(the web extension) and the user.
The chromium documentation about content-scripts warns hence:
Stay secure
While isolated worlds provide a layer of protection, using content
scripts can create vulnerabilities in an extension and the web page.
This question seesk for an answer if,
a) it is impossible to have a UI in the content area of a web page, that cannot also impacted by the web pages javascript (i.e. the DOM being always modifyable for both the content-script and the web page's javascript) or
b) there is a way to present a UI inside the content area of a web page, while in a "safe way" (meaning the web pages untrusted javascript, cannot impact the UI displayed).

How to force external links to open in an existing web app?

I cannot find anything about it but I find it hard to believe no one has ever tried this.
I'm looking for a client-side solution that allows me to re-use an existing web application running in a browser tab/window when a link is 'clicked' externally.
For example, someone sends me en email with 10 links pointing to a web app (http://myapp.com/:id)
I just want a single instance of that web app to avoid opening a new tab when a link is clicked. My app is really heavy to load and already manages its own tabs re-using existing data.
I've currently implemented this using a Chrome extension that closes the tab if there is an existing one with the same domain, but I want a better cross-browser solution (at least Firefox)
Does anyone know how to achieve this using JS?
I was thinking of Shared workers, but I'm sure there is no way to focus a browser tab using JS...
Thanks!

Meteor: Reuse existing browser tab with each (Android) NFC tap?

I'm developing a Meteor web app that loads upon tapping an NFC tag (Android). I'm finding that (of course) tapping the same NFC tag (with the same embedded URL) opens a new window or tab in the browser. The problem is three-fold: 1) it clutters the browser with multiple tabs referencing the same web app thus confusing the user, 2) grows browser memory, and 3) forces Meteor to perform a complete (and slow) download for the new tab rather than reusing the same web app already loaded. The appcache package does not seem to make a difference in this case. This delays the page from appearing quickly after a tap because of the app reload.
Is there any (clever) way around this? I would hope to reuse an existing tab with the same hostname/domain to avoid all of the issues above. I don't know enough yet about HTML5 Javascript API that might offer some kind of solution. I'm afraid this might not be possible. I was thinking, if it were possible, I could load a small app first that inspects the browser environment, redirecting to the full Meteor app, or finding an existing window/tab with same hostname and fetching a new url within that window (with the updated tag ID for instance).
Someone might suggest using Meteor native mobile app, but this has several other problems of its own, including the fact the app must be installed via Play store which is friction vs. web app that just loads without installing an app. Thanks in advance.

Deep linking javascript powered websites

I have a website which has two versions, an all singing all dancing javascript powered application which is served when you request the root url
/
As you navigate around the lovely website the content updates, as does the url, thanks to html5 push state or good old correctly formatted #! urls. However if you don't have javascript enabled you can still use all functionality of the site as each piece of content also exists under it's own url. This is great for 3 reasons
non javascript users can still use the site
SEO - web crawlers can index the site easily
everything is shareable on social networks
The third reason is very important to me as every piece of content must be individually shareable on the site. And because each piece of content has it's own url it is easy to deep link to that url, and each piece of content can have it's own specific open graph data.
However the issue I hit is the following. You are a normal person and have javascript enabled and you are browsing and image gallery on the site and decide to share the picture of a lovely cat you have found. Using javascript the url has been updated to
/gallery/lovely-cat
You share this url and your friend clicks on it. When they click on the link the server sends you the non javascript / web crawler version of the site, and the experience is no where near as nice as the javascript version you would have been served if you directly went to the root of the site and navigated there.
Do anyone have a nice solution / alternative setup to solve this problems? I have several hacks which work, however I am not that happy with them. They include :
javascript redirect to the root of the site on every page and store a cookie / add a #! to the url so on page render the javascript router will show the correct content. ( does google punish automatic javascript redirects? )
render the no javascript page, and add some javascript which redirects the user to the root, similar to above, whenever the user clicks on a link
I don't particularly like either of these solutions, but can't think of a better solution. Rendering the entire javascript app for each page doesn't appear to be a solution to me, as you would end up with bad looking urls such as /gallery/lovely-cat/gallery/another-lovely-cat as you start navigating through the site.
My solution must support old browsers which do not implement push state
Make the "non javascript / web crawler version of the site" the same as the JavaScript version. Just build HTML on the server instead of DOM on the client.
Rendering the entire javascript app for each page doesn't appear to be a solution to me,
That is the robust approach
as you would end up with bad looking urls such as /gallery/lovely-cat/gallery/another-lovely-cat
Only if you linked (and pushStateed) to gallery/another-lovely-cat instead of /gallery/another-lovely-cat. (Note the / at the front).
Try out this plugin it might solve your 3rd reason, along with two reasons.
http://www.asual.com/jquery/address/

How to screen scrape across origins in an IFRAME?

I have a business web app that needs to pull in information from various other web sites. For most sites, the user just instructs the server to pull the data (either using .NET's HttpRequest, or Selenium).
But for some unfriendly, Javascript-heavy sites, our users have to visit the site manually, navigate to the right spot, and copy and paste into our application.
Other than bookmarklets, is there any way for our page to show an IFRAME with the source web site loaded, allow the user to navigate within the frame, and then capture the IFRAME's body?
Since the site in the IFRAME isn't in the same domain (not even close), I can't seem to work around browser cross-site scripting limitations. I've tried using HTML5's "sandbox" feature, but it appears to only allow communication (via "allow-same-origin") the other way, from the IFRAME to the host site, which isn't useful to me. Also, it doesn't work if the site in question attempts to load its frames to the top context.
What I'm ideally looking for is a solution that would allow the browser to be configured to trust my web site implicitly (it's an intranet app) and allow it to access any frame's contents. That would at least get me in the ballpark. Bonus points if I can get the iframe to redefine the "top" context as its own frame, so the hosted site functions properly within the frame.
The best approach I've found through many many screen scraping projects (scraping JS heavy pages) is to create a user-script or Greasemonkey script, setup a few virtual machines in their own IP space (for protection) and feed them a list of sites to visit from a remote program:
Check the queue at a set interval
Request page with Greasemonkey, etc.
Capture contents and send to remote program for processing
You can't use an iframe method and you are going to bang your head up against a wall trying to go that route, the method I've described has worked for numerous large-scale scraping projects.

Categories