I'm trying to open an html page (I get it as a string and parse it) from my fullscreen iOS web application (standalone).
I tried opening a window (window.open) but it doesn't work.
It involves handling a payment method, so I can't redirect back from their page to mine (it's an illegal hack) when I finish.
How can I manage opening the html file in safari and going back?
I don't know of a way that a standalone mode web app can serve up raw HTML to the user without it being hosted somewhere.
If you have a genuine web URL though, you can have the user click a link with target="_blank" (new tab) and it should open in Safari, instead of the standalone browser. I don't think you can do it via window.open(), because it will be silently blocked as a "pop-up".
Related
Background to explain the issue
I have a Java desktop application that as part of a task creates an HTML report and loads it directly into the user's preferred web browser. This is how it works on a PC or mac.
The Java app can also run in remote mode, in this case the whole interface is in a web browser. The main purpose of this is it can then be installed on a NAS and controlled remotely via PC/iPad etcetera, and everything including the HTML report is loaded from the web server running the application.
The trouble with the application is that Safari on mac doesn't like the HTML files to be loaded directly into the web browser, and this (sometimes) prevents the loading of resources and causes the the HTML report to not be rendered correctly.
The solution is for my application to run a simple web server that always serves the report files so the browser would open http://local:4567/report1.html rather than file://C:/application/reportslocation/report1.html -- in all cases.
Cancel Button Problem
This works but now I have another problem: the report has a Cancel button which should not be shown when running in desktop mode, because this is the first page, so it can't be canceled, whereas remote mode takes you to the start page.
What I used to do was to check the currently loaded URL, and if it starts with file:, hide the button:
if (window.location.protocol == 'file:') {
document.getElementById('return').style.visibility='hidden'
}
But now all files are served via HTTP, so I changed it to
if (!document.referrer) {
document.getElementById('return').style.visibility = 'hidden'
}
and it works for the first page of the report because referrer is not set when loading from the desktop app.
However there are multiple pages of reports, so when I click on a link to open another page of the report, the Cancel button is now incorrectly displayed because document.referrer is no longer empty.
So my thought was, if I could get the original referrer when opening a page, I could then correctly check if the Cancel button should be displayed.
Also note, the reports may have been created in desktop mode and then viewed later on in remote mode or vice versa. So the report is only created once and has to be valid for both cases.
If you are using the http protocol and not the file protocol then I think it would be fine to use the browsers localStoreage.
Such as on the first page:
if (!document.referrer) localStorage.setItem('mode', 'desktop')
Then on following pages
if (localStorage.getItem('mode') === 'desktop') document.getElementById('return').style.visibility='hidden';
However if you are using the file protocol then a new store is created for each file, so they won't be transferred/accessible.
Another more hacky option could be to contain this information in your href as a query param if you are in desktop mode or not.
I am writing a mobile web page which has both a redirect and two manual backup links (for when the redirect doesn't work) to a Facebook Page.
The link takes the form:
fb://page/[PAGE ID NUMBER]
The redirect and link work in Chrome Mobile and Firefox Mobile but (surprise) they don't work in Facebook Browser which, instead, gives me the error:
Page can't be loaded.
I am perplexed that a link to the Facebook App doesn't work from within the Facebook Browser.
How can I resolve this? Are there any creative solutions or workarounds... or have I missed something obvious?
Additional Info: It looks like the redirect is working in at least one version of the Facebook Browser on the Facebook iOS App. So the issue may be isolated to the Facebook Android App.
UPDATE 1
I've made some progress. I've discovered that Facebook's in-app browser doesn't always (or doesn't ever?) acknowledge / load / execute external script files.
Added: (To find out why not, see Update 8, below...)
In this case the href attributes in the links were being re-populated with fb:// protocol links by an external script after page load.
I have moved the relevant javascript functions from the external script to the bottom of the actual page. I have tested the functions and I can see they are now activating. Although the links still don't work.
UPDATE 2
It struck me that there may be some security mechanism going on behind the scenes which doesn't allow for any javascript-driven re-population of href attributes and that instead of the fb:// protocol links not working, it was maybe the case that the initial, default http://www.facebook.com/ links were never even being replaced and it was those http:// protocol links that weren't working.
So I updated the PHP template, so that the initial default links were the fb:// instead of the http:// links (so nothing in the page delivered to the Facebook in-app browser would need to be updated by any client-side script at all at any point).
Nope. Still not working.
UPDATE 3
I added a plain vanilla link to the bottom of the page, linking to the site's homepage. The link functioned entirely normally.
Later, I pointed the original links to an external domain. They didn't work.
So... I concluded that only http:// protocol links to the same domain would work and that's why the links wouldn't work if they pointed to an external domain or to an fb:// protocol address.
Wrong conclusion.
I pointed the original links at the site's homepage and they still didn't work.
UPDATE 4
In a moment of inspiration, I removed the reference to the external script which I'd set up to customise the links to the OS + browser environment (even though this script reference was being entirely ignored by Facebook, according to the FB Debugging tool.
The links worked.
So the reason why the plain vanilla link I had added earlier had worked, was nothing to do with where it was pointing and simply to do with the fact that at no point had a script tried to access it or update it.
Added: (This isn't the reason. See Update 8, below...)
I pointed the original links at the external domain. They worked.
I pointed the original links at the fb:// protocol. They didn't work.
UPDATE 5
Now that I've got rid of the external script reference, I can point the original protocol links at any http:// protocol address and they work.
Including the http://www.facebook.com web equivalent of the page I am trying to open in the Facebook App.
Let's review that:
The Facebook website is opening in the Facebook in-app browser.
I know, right?
UPDATE 6 [.HTACCESS REDIRECT]
I changed the link destination to /fb-custom-redirect/.
Then I added a line to the mod_rewrite section of my .htaccess file:
RewriteRule ^fb-custom-redirect fb://page/[PAGE ID NUMBER]
Naturally the server didn't understand what I was asking for.
UPDATE 7 [PHP REDIRECT]
I created an index.php for /fb-custom-redirect/ and added the following:
<?php
header('Location: fb://page/[PAGE ID NUMBER]');
?>
Guess what? This works in Firefox Mobile. It also works in Chrome Mobile.
But in the Facebook in-app browser, it returns the same error:
Page can't be loaded.
UPDATE 8
I've only just discovered - and this is not insignificant - that when the Facebook Debugger Tool (https://developers.facebook.com/tools/debug/sharing/) refreshes Facebook's cache of a given page, it only refreshes the .html.
Pressing Scrape Again does not refresh any external resources like .css and .js files.
Instead Facebook continues to refer to its own cached versions of those files, regardless that the .html file cache has just been updated.
The workaround (in PHP, at least) is to append the filepath with a new, randomly generated query string every time the page is loaded:
<link rel="stylesheet" href="/styles/mystyles.css?'.uniqid().'" />
Now the Facebook in-app browser is fetching up-to-date versions of my .css and .js files.
This explains my initial observation in Update 1:
I've made some progress. I've discovered that Facebook's in-app
browser doesn't always (or doesn't ever?) acknowledge / load / execute
external script files.
I'm going to conclude that the Facebook in-app browser was parsing the external .js file reference every time, but it was repeatedly accessing an old, cached version of that file.
Nevertheless, even after all the hypotheses and experimenting above, I'm still no closer to discovering why fb: protocol deeplinks don't work in the Facebook App's in-app browser.
I give up.
Apple apps are sandboxed. This means they cannot access other apps and execute code. Facebook is running a browsing instance and when you try to call the fb:// protocol, the iPhone is blocking you from doing this to try to create an infinite app loading loop. I.e, you open a page in FB browser and it opens itself in FB browser and it opens itself in FB browser...
I'm trying to develop a Chrome extension that is supposed to completely replace a specific website's pages with a new UI. In other words, when the user visits said website, the extension should "intercept" it seamlessly and display the new "app" (preserving the URL and without opening a new tab or window). I currently use a content script to manipulate the DOM, but it's too messy.
Chrome apps such as Google Docs achieve the same goal through URL handlers, but they're not an option since they're now deprecated.
Currently, I'm aware of two options:
Intercept the URL and redirect it to an extension URL. I want the URL to be preserved.
Use a content script to stop the page from loading at document_start (using window.stop()) and then "inject" the new app. Apparently, that works, but it sounds quite hacky and prone to unexpected glitches.
What I'd like to know:
Is the second approach good enough? What limitations and other issues will I face if I use it?
Is there any other approach that is at least as good (and preferably designed for this purpose)?
You can't open a chrome app in a tab, only in a window. I don't think they have content scripts either.
Also, chrome apps are now only available on chrome os when you publish it for the first time (existing chrome apps work for any os).
To solve your question, you could use an extension with content scripts and just open up an iframe fullscreen so the url is preserved in the omnibox and it could have the page you want in the iframe as the page that would be in the app.
Content handlers are meant for opening a special protocol url to do something like send an email, etc. Examples would be like tel://, sms://, mailto:, etc.
So you would not want this. Also they aren't that noticable when approving to handle the protocol.
On button click I want to open the default metro browser (usually IE) without opening a new tab/page, just open the browser, If it is already running then just switch to it as it is to it's current state. Is there a way to do that?
This is just something to try, and may or may not work in your scenario:
If you know the url that is open in the browser, your Windows Store app could launch that same url with the launcher.
In my app, when I launch the same url multiple times, IE will pop up but will not load a second instance of the url.
No. The only way to launch the browser is indirectly through the Launcher. The Launcher requires a Uri or a File and it will open the default program associated with that Uri or file type. If it is http, for example, it will launch the default browser. Unfortunately, it seems that the Uri class does not properly parse the about Uri scheme nor will it accept a blank string or http address without a host.
I am developing an extension that fetches pages that the user is likely to access on a website. My extension uses jQuery.get() to fetch a page. This works correctly for a site like amazon.com.
But if the user logs in to gmail and I try to fetch some other pages like "account settings", I get an incomplete page. Somewhere in that page, I get the message:
"Your browser does not support Javascript or Javascript has been disabled.As your browser does not support Javascript or has Javascript disabled, we are not able to display the requested page."
Is there some way to fetch complete page in such cases?
I ended up opening a new tab and fetching the page in that tab. Then using content script, I analyze the page data. Sure this is a problem in the sense that a user will see newly opened tab. But then it is also transparent to the user.
If you are developing an extension on Firefox using Jetpack, you can use page-worker which is an invisible page and gives access to the DOM.