New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 68 users
Status: Fixed
Closed: Jan 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Bookmarklets run on hosted apps think that location.href is about:blank
Reported by, Aug 17 2011 Back to list
Chrome Version       : 

Google Chrome	13.0.782.112 (Offizieller Build 95650) m
Betriebssystem	Windows
WebKit	535.1 (branches/chromium/782@91904)
JavaScript	V8
Flash	10,3,183,5
User-Agent	Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1
Befehlszeile	"C:\Users\sh\AppData\Local\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Ausführbarer Pfad	C:\Users\sh\AppData\Local\Google\Chrome\Application\chrome.exe
Profilpfad	C:\Users\sh\AppData\Local\Google\Chrome\User Data\Default

URLs (if applicable) :

Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 5.0: OK
       IE 8: OK

What steps will reproduce the problem?
1. Create a bookmarklet with URL "javascript:alert(document.location.href);" and store it in your bookmarks.
2. Go to one of the above mentioned sites
3. Click on the bookmarklet.

What is the expected result?
A dialog box with the URL of the site.

What happens instead?
A dialog box with "about:blank".

Please provide any additional information below. Attach a screenshot if

45.0 KB View Download
Some more comments:
- This also happens on some http:// sites (
- This also happens with location.href
- alert(location.href) works on the console
Occurring for me too on OS X 10.7, Chrome build 13.0.782.112.

Putting document.location.href into the Chrome Javascript console gives the URL (which can then be passed to an alert).  The alert works on majority of other sites (including ones using HTTPS), but confirm this issue occurs on the Evernote site.

Using the latest Canary build (15.0.857.0 canary), is fixed, but when accessing account pages when signed in still returns the about:blank error.
Comment 3 by, Sep 26 2011
this also happens on (logged in, Chrome Version
Comment 4 by, Oct 4 2011
RockMelt (Official Build a7d74ed)
OS Windows
WebKit 535.1 (branches/chromium/782@93192)
JavaScript V8
Flash 10,3,183,10
User Agent Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) RockMelt/ Chrome/13.0.782.218 Safari/535.1

Alert returns about:blank for every page.
Works from the console.

Comment 5 by Deleted ...@, Oct 9 2011
I've setup a testing environment with portable chrome from version 8 to 15 dev

This issue began to occur since version 12 and all of the later version, any web address with a query string will fail to respond the correct value but return "about:blank" instead. sadly I could not find any solution for bookmarklet on the web.

At the moment, I would suggest to wrote a user script instead (well... it will take a little space on the page for the link placeholder)
Also present on 16.0.904.0 dev, for the following URLs:
Comment 7 by, Nov 10 2011
Also present on 17.0.932.0. Same URLs/issues as previous reporters.
Comment 8 by, Nov 26 2011
Also present on 17.0.942.0 for and subpages.
Comment 9 by, Dec 14 2011
Still present in 17.0.963.6
I see the exact same problem(s), but only on my laptop running Chrome under Vista. My desktop is running Windows 7 and document.location works just fine. Chrome is synced between the two machines, so the settings, extensions, etc. are the same.
Labels: -Area-Undefined Area-UI Feature-Bookmarks Feature-DevTools OS-Windows
Status: Untriaged
I see this happening in 17.0.963.12 on windows 7.

In ubuntu, the bookmark doesn't work at all.
Comment 12 by Deleted ...@, Dec 16 2011
I started having this issue with Chrome 16.0.912.63 and specifically with I was able to fix the issue by removing Youtube from the Chrome apps tab.  Now when I use my bookmarklet location.href returns the correct value.
Removing the YouTube app fixed the problem for me under Vista too. :)
Yes, the fix of #12 did the trick for me, too (Windows 7, 16.0.912.63)! For both URLs originally repported, I had an app entry. Removing the app entries resolved the issue (had to open a new tab first).

Thanks! So the issue could be renamed: "document.location.href does not work within a bookmarklet when website is also a Chrome app".
Labels: -Feature-DevTools
 Issue 108259  has been merged into this issue.
Labels: -OS-Windows OS-All Feature-Apps
Summary: Bookmarklets run on hosted apps think that location.href is about:blank (was: NULL)
It seems like javascript: URLs trigger at least a partial page navigation when run on hosted apps (e.g. the dev tools console gets cleared), which might explain why Chrome then thinks the URL is about:blank.
Status: Available
Comment 20 Deleted
This seems to be happening  to any site I navigate to via google searches triggered from the location bar as well.  Selecting the location bar and hitting <Enter> to refresh the page on the target site seems to remedy, while a direct refresh does not.

Google Chrome: 16.0.912.63
Mac OSX: 10.7.2
Mihai, I believe Pavel made a change regarding bookmarklets triggering a partial page reload so they would update the DOM view a number of months ago.
Comment 23 by, Jan 3 2012
Does anyone know of a workaround for this issue which can be applied to bookmarklet code rather than asking users to uninstall Apps ?

Additionally is there any outlook for fixing this problem ? I haven't tested this, but try:

javascript:void(document.body.innerHTML+="<script onload='myCode()'>myLocation=location.href</script>",function myCode(){ alert(myLocation); }); said:

I haven't tested this, but try:

onload='myCode()'>myLocation=**location.href</script>",**function myCode(){
alert(myLocation); });

document.body is empty.  Meaning that this will append a script, but it
won't get you the URL of the web page.

The same issue in my bookmarklet. Fixed it by deletion of the Youtube and Google Search apps from the chrome. After the script injection window.location.href becames about:blank. and the body is empty.
Happens to me (breaking several of my frequently used bookmarlets) with many pages, and sometimes a refresh fixes it, sometimes not.  Chrome 17.0.963.26. What #23 says.
Comment 28 by Deleted ...@, Jan 6 2012
This happens to me if I either

1) visit 


2) Do a search via the url bar.

Then ALL bookmarklets are broken.
Comment 29 by Deleted ...@, Jan 9 2012
Hey everyone - 

It is the Youtube application in Chrome which causes the problem because it is running as an application not actually a webpage. If you uninstall the youtube application from chrome (by going to the apps screen, right click and then uninstall) - everything works as expected.
Comment 30 by, Jan 9 2012
YouTube is not the only case.
e.g. The same problem occurs for the Evernote Web Client.
Comment 31 by, Jan 9 2012
My comment should have read.
The same fix (removing from New Tabs -> Apps page) also works for Evernote Web Client.
Status: Started
I'll take a look.
It looks like RenderViewHostManager is forcing a process swap on JavaScript URLs when we're currently showing a hosted app.  This is a side effect of introducing the SiteInstance::HasWrongProcessForURL call to GetSiteInstanceForEntry, since HasWrongProcessForURL returns true.

Should be a simple fix of just checking IsURLSameAsAnySiteInstance within HasWrongProcessForURL.  (Note: Nasko is helping me with this one as a starter bug for him.)
Though it might be a separate bug, I also thought that bookmark apps (the default YouTube, Search and Gmail apps are bookmark apps) don't get process isolation; I'm surprised that HasWrongProcess returns true for them.
Comment 35 by, Jan 10 2012
Yeah, I wouldn't expect that either.  Javascript links work on the YouTube bookmark app on my tip-of-tree build, but not on the Chrome Canary (18.0.997.0).  I wonder if those aren't being treated as bookmark apps for some reason?
The YouTube app was recently updated (on 1/4 per, the new icon is different), perhaps the "is bookmark app" bit was lost when the external extension got updated.
Project Member Comment 37 by, Jan 14 2012
The following revision refers to this bug:

r117744 | | Fri Jan 13 17:05:31 PST 2012

Changed paths:

Don't swap processes for javascript: URLs.

BUG= 93199 
TEST=Enter "javascript:alert(document.location.href);" in the omnibox while in a hosted app.

Review URL:
Comment 38 by, Jan 17 2012
For me, if I do a search in the URL bar (rather than a Google search page), my bookmarklets return About:blank. If I simply copy the URL returned from the search and re-paste it in the bar, the bookmarklets work. This just started happening in the latest update.
That's because you have the "Google Search App" installed – your new tab screen should have an icon for Google Search. If you right click on it and "remove" it, bookmarklets should work again
Comment 40 by, Jan 18 2012
Wow, just read/got Comment 39. I removed YouTube App(didn't realize the apps were there, had been looking all over for them Chrome>Tools, Extensions, etc..), and problem solved for me! i.e. Removed YouTube App and Bookmarklet works on YouTube URL's now!..Btw, YouTube only enables downloading, which I don't use/worth removing to get back Bookmarking functionality.. That is/was the problem, right? Thanks for this excellent venue..
Comment 41 by, Jan 18 2012
Labels: Mstone-17 Merge-Requested
Status: Fixed
This was fixed by Nasko's CL in comment 37, which made sure that JavaScript URLs don't get sent to a different renderer process.  The fix is available on the Canary builds of Chrome as of 18.0.1010.0.

Jason, I've verified that the fix works on the Canary.  Shall we merge this one to M17?
Comment 42 by, Jan 18 2012
Labels: -Merge-Requested Merge-Approved
Project Member Comment 43 by, Jan 18 2012
Labels: -merge-approved merge-merged-963
The following revision refers to this bug:

r118145 | | Wed Jan 18 12:55:17 PST 2012

Changed paths:

Merge 117744 - Don't swap processes for javascript: URLs.

BUG= 93199 
TEST=Enter "javascript:alert(document.location.href);" in the omnibox while in a hosted app.

Review URL:
Review URL:
 Issue 108463  has been merged into this issue.
I used to have the issues described above (i.e., bookmarklets not working on certain domains associated with installed apps). However, now none of my bookmarklets work at all. This happened when the dev channel was updated to Chrome 18. I am using Chrome 18.0.1010.1 dev-m on Windows XP (work) and Windows 7 machines (home).
Comment 46 by, Jan 24 2012
Re: comment 45:
The fix is included on 18.0.1010.1 dev, and I can't reproduce the problem on that version on Windows.  It sounds like you're encountering a different bug, so I'd recommend filing a separate report.
Re: comment 46:
I've been doing a bit of research and it appears that my problem is specific to Javascript prompt boxes. For example, if I press the "show prompt box" button on this page ( and change the default text of "Harry Potter" to another name such as "John," then Chrome should display "Hello John! How are you today?" Instead, nothing happens. However, if I leave the default text of "Harry Potter" in the prompt box, it correctly shows the result "Hello Harry Potter! How are you today?"

I'll file a separate report since it is clearly a separate problem.
I submitted a new issue for the Javascript prompt box bug. It can be found here:
Comment 49 by Deleted ...@, Aug 22 2012
En un tiempo me funcionó muy bien el navegador de Google, pero luego me fallo con los vídeos de youtube, entonces instale Opera, y que es compatible con Google. y me funciona bien.
Comment 50 by, Aug 22 2012
@comment 49: Please file a new bug if you see issues with YouTube in Chrome.  That's not related to this report.
Project Member Comment 51 by, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 52 by, Mar 10 2013
Labels: -Area-UI -Feature-Bookmarks -Feature-Apps -Mstone-17 Cr-Platform-Apps Cr-UI-Browser-Bookmarks Cr-UI M-17
Project Member Comment 53 by, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Comment 54 by, Jul 24 2013
Sign in to add a comment