I'm using a class to register my protocol, lets say lorem: to operating system. Its working perfect but I would like to do couple of things.
I want to create something like Skype Click to Call. People will share uri's like lorem://12345678 and when others click this the event handler will redirect that request to my windows application. I want to make this uri clickable. How can identify this new scheme to browsers so when a page contains lorem://12345678, browser will transform it something like
lorem://12345678 and users be able to click it.
Can I do it with browser configuration or should I write some kind of extension to implement this rule. It must support all browsers so is that means I need to write same extension for Chrome, Firefox and IE? And how can I install all extensions with my software setup?
Straight to point question: I want to transform lorem://ipsum text to My URL! on most popular browsers
as i understood -- you need to write extensions for each browser, check out this question:
how do I create my own URL protocol? (e.g. so://...)
and this is an example of browser approach:
Custom protocol handler in chrome
Related
I am doing some debugging and would like to see the full URLs in developer tools, but I could not find a way for that.
Therefore I would like to know:
Is there a way to achieve it? If not, then how do I deal with it?
Why Chrome by default is not showing this info? I don't think it could be a security issue, as Chrome is displaying all other sensitive info.
Example:
When I go to https://stackoverflow.com/abc#qwerty:
This is what I see in the network tab:
What you see in the dev tools are the request that are sent to the server. What’s behind the # is actually not sent to the server, it’s used by SPA (single page application) to keep track of the state between pages
You can use Firefox for this case, their Dev Tools show the full URI including the fragment identifier after the hash sign.
Alternatively, you can view it in JS console using location.hash property:
screenshot
I would like to be able to open a tab in Chrome and enter something like gs://bucket-name/path/to/file and have it open the corresponding page in the GCP Web Console https://console.cloud.google.com/storage/browser/bucket-name/path/to/file. I saw there are external protocol handlers in Chrome, but I don't want to open an external application. I just want it to open another page based on the URI. I also don't want to put up any of my own servers for this simple purpose. Perhaps a Chrome Extension that can do some simple JS on the URI after I enter it into the address bar?
I think it is possible now with link you gave (works for me).
#shiv turned my attention on fact that this is question about automated link replacement under the hood in address bar when you write "gs://bucket-...". So such handler just collects address and modifies it and uses modified version to go further.
Well then looks like you need something like this Set custom protocol handler in Firefox? (in case of Firefox) but unfortunately I cannot help more.
I'm building a single-page Dart web app that will essentially consist of 1 Dart file (cross-compiled to JS) and 1 HTML file that has several "views" (screens, pages, etc.). in it. Depending on what "view" the user is currently located at, I will hide/enable different DOM elements defined inside this HTML file. This way the user can navigate between views without triggering multiple page loads.
I would still like to use each browser's native history-tracking mechanism, so that the user click can the back- and forward-buttons in the browser, and I'll have a Dart Historian object figure out what view to load (again just hiding/enabling DOM elements) depending on what URL the browser has in its history.
I've pretty much figured everything out, with one exception:
Say the user is currently "at" View #3, which has a URL of, say, http://myapp.example.com/#view3. Then they click a button that should take them to View #4 at, say, http://myapp.example.com/#view4. I need a way, in Dart, to tell the browser to:
Set http://myapp.example.com/#view4 in the browser URL bar
Add http://myapp.example.com/#view4 to the browser's history
If not already enabled, enable the browser's back button
I believe I can accomplish #1 above like so:
window.location.href = "http://myapp.example.com/#view3";
...but maybe not. Either way, how can I accomplish this (Dart code communicates with browser's history API)?
Check out the route library.
angular.dart also has it's own routing mechanism, but it's part of a much larger framework, so unless you plan on using the rest of it, I would recommend the stand-alone route library.
If you want to build your own solution, you can take a look at route's client.dart for inspiration.
There are two methods of history navigation supported:
The page fragment method that you've used. Reassign the window location to the new page fragment: window.location.assign(newPathWithPageFragment). Doing this will automatically add a new item to the browser history (which will then enable the back button).
The newer History API, which allows for regular URLs without fragments (e.g. http://myapp.example.com/view3. You can use window.history to control the history.The History API is only supported by newer browsers so that may be a concern (although given that dart2js also only supports newer browsers, there are probably not too many instances of a browser that dart2js supports that doesn't support the History API).
One issue you will have to handle if you support History API is the initial page load. When a user navigates to http://myapp.example.com/view3, the browser expects to find a resource at that location. You will have to setup your server to respond to any page request by serving your Dart application and then navigate to the correct view on the client-side. This issue will apply whether you use route, angular.dart, or build your own solution, since this is a general server-side issue and the above are all client-side libraries.
When I'm viewing the downloaded resources for a page in the Chrome web inspector, I also see the HTML/JS/CSS requested by certain extensions.
In the example above, indicator.html, indicator.js and indicator.css are actually part of the Readability Chrome extension, not part of my app.
This isn't too big a deal in this particular situation, but on a more complex page and with several extensions installed, it can get quite crowded in there!
I was wondering if there was a way to filter out any extension-related resources from this list (i.e. any requests using the chrome-extension:// protocol).
Does anyone know how I could achieve this?
Not quite the solution I was after (I'd have preferred a global setting), but there is now a way to filter out requests from extensions, as mentioned by a commenter on the issue I originally opened.
In the network tab filter box, enter the string -scheme:chrome-extension (as shown below):
This is case-sensitive, so make sure it's lowercase. Doing this will hide all resources which were requested by extensions.
Just enter "-f" in Network field
Was having the same question when my extension adds a lot of noise in the network tab.
Some extensions also fire a lot of data like data:text/image etc, you can append more filter with - like:
-scheme:chrome-extension -scheme:data
Another way to get the http/https requests is to just use scheme:https without - because the resources that extensions request are usually from their local bundle:
scheme:https
An Incognito Window, can be configured to include or exclude extensions from the extensions page of Chrome settings.
One alternative is to go to "Network Request blocking" tab and add "chrome-extension:" to the list, thus extension requests will be blocked and coloured red so it's easy to visually filter them out.
you can simply enable this option and requests from extension will be group.
Update: It can only group requests that create by the extension that draw iframe, such as cVim
Is there a way to implement a mailto: link that works with webmail clients?
Edit - so a traditional mailto link is (as I suspected) not going to work. So has anyone seen anything similar to those rss buttons you see with a variety of the most popular sites on?
The links are handled by the user's browser. GMail has a client-side install (GMail Notifier) that lets you specify that you want GMail to handle all mailto links.
But there's no way for a web page to specify that it's mailto link should be handled by a webmail app (even if it could, how would you know which one?).
That's really more of a web client issue, it's already available for Firefox:
http://starkravingfinkle.org/blog/2008/04/firefox-3-web-protocol-handlers/
but ultimately it's down to the user to decide how their browser handles mailto links.
Create a text file named MailtoWebMail.reg with the following content...
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell\open\command]
#="\"(BrowserExecutable)\" (Parameters)"
where (BrowserExecutable) is replaced with the complete path to your browser (ie. C:\Program Files\Internet Explorer\iexplore.exe)
and (Parameters) is replaced with the appropriate line for the mail service as described below...
GMail
"http://mail.google.com/mail/?view=cm&fs=1&to=%1"
Hotmail
"http://hotmail.msn.com/cgi-bin/compose?To=%1&mailto=1"
Yahoo Mail
"http://compose.mail.yahoo.com/?To=%1"
Netscape Mail
"http://webmail.netscape.com/compose.adp?mailto=%1"
Mail.com
"http://mail01.mail.com/scripts/mail/Outblaze.mail?composeto=%1&compose=1"
Opera Web Mail
"http://mymail.operamail.com/scripts/mail/Outblaze.mail?compose=1&did=1&a=1&to=%1"
Note: There should not be a blank line after the [HKEY_LOCAL_MACHINE] line
MikeB
I am just brainstorming here. You might be able attach a Javascript handler to the link that asks the user if s/he wants to login to a webmail account (along with a list of providers). If you have the correct URLs for the webmail providers, you would then be able to invoke them on the basis of the user's choice. If the user answers no, return true from the handler and presumably the link would work normally.
See, for example, http://toric.blogspot.com/2005/07/gmail-compose-link.html and http://blog.monstuff.com/archives/000238.html
Here are 2 Opera UserJS examples that you can inspect to give you and idea of how you can do it on a regular pages. (Obviously, UserJS-specific functions wouldn't work in a regular page, but you can use regular events.)
This one catches left-clicks on mailto links and opens them in Gmail for example. It can also handle forms.
http://shadow2531.com/opera/userjs/BeforeMailtoURL.js
This one catches all mailto actions, has a more generic parser (that supports any hname and not just to, cc, bcc, subject and body) and has a better format string syntax:
http://shadow2531.com/opera/userjs/BeforeMailtoURL.zip
Basically, you have to find a way to intercept mailto link actions. You can do this with click event listeners on links and submit listeners on forms (if you really want to support forms). (It's easier to use a click event listener on the whole window and just filter it to find mailto actions. That way, you catch mailto links that are dynamically added at some arbitrary time.)
Or, you can just run through the page and process all the mailto links.
But, if you want to intercept mailto actions in the address field, via window.open or document.location etc., you'll need something like HTML5's registerProtocolHandler or something like Opera's webmailprovider.ini support. You can use registerProtocolHandler in Firefox, but by default, it's restricted to the domain you set it on.
So, basically, you either convert mailto links to http(s) webmail compose URIs up front, or at the time the mailto action is invoked. The latter works much better.
Converting a mailto link to a webmail compose URI involves a few things. First, you need to know what query string variables the webmail accepts. Then, you need to parse the mailto URI to split it up into the parts you want. Then, you need to decode and re-encode (to normalize) those parts. Then, you need to join multiple occurrences of hvalues together. And, you need to handle things in a case-insensitive manner and check for and escape unsafe characters and %HH etc.
For the parsing, you can do a quick and dirty regex, but you'll get better results with a full mailto URI parser and normalizing functions.
So, if you just want to handle left-clicking on links, you can do that cross-browser. For more than that, you have to use any hooks the particular browser gives you.
Hypothetically, assuming the webmail client passes arguments through the authentication process (or the user is already authenticated), I don't see why this is so impossible. It can't be done in the simple mailto: way, but it'd be possible to provide a selection of links to popular webmail services and use Javascript to intercept clicks on mailto: links such that the user is presented with a drop-down list of possible webmail services (or their local email client). The links would carry the To:/Subject: address but formed in whatever structure that webmail service requires.
If you're using a Google Apps email account (hosted email), than Gmail Notifier will not work. You can use a bookmarklet though, to change all of your mailto: links to links that point to your webmail.
Here's a bookmarklet I wrote to do just that, it will highlight all fixed links in red.
javascript:for(var i=0;i<document.links.length;i++){var a=document.links[i];if(a.href.indexOf('mailto:')==0){a.href='http://mail.google.com/a/sample.com/mail?extsrc=mailto&url='+a.href;a.style.backgroundColor='red';a.style.color='white'}};return true;
Just be sure to change http://mail.google.com/a/sample.com to whatever the proper hosted address is for you.
I suppose this will work with a number of other email clients if you just change that link around.
Kind of an old thread, but nobody has quite answered it yet, so here goes.
As blesh nearly says above, while there's no way to get "mailto:" to go to Gmail, there's another way to skin this cat that works just fine in many situations. Just change the URL. Remove the "mailto:" prefix and insert "https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=".
This seems to work like a charm, whether or not the user is coming in through Google Apps. If the user is not logged in, he'll be walked through that step, and then Gmail will still kick off a new message. The only downside I've noticed is that if (when?) Google decides to change their bookmarking scheme, this may need a bit of tweaking.
It may make sense to perform this transform either before or after the URL is in the DOM, depending on your situation.
Oh and double click the MailtoWebMail.reg to insert the command into your registry.
MikeB
Has anyone seen numbers indicating what percentage of webmail users have configured their systems with plugins etc. to properly have mailto: links sent to their browser / webmail system rather than to a desktop app? This seems critical in deciding whether to use mailto: links on a site or a contact form, but I'm having trouble coming up with numbers to guide the decision.