413540 - Never open javascript: bookmarklets in a new tab/window

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Bookmarks, defect)

Description

[Scheichi]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de; rv:1.8.1.11) Gecko/20071128 Camino/1.5.4 (MultiLang)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de; rv:1.8.1.11) Gecko/20071128 Camino/1.5.4 (MultiLang)

JavaScript bookmarklets (such as the increment/decrement link bookmarklets from PimpMyCamino) should act on the currently displayed webpage, which they do when you choose the corresponding menu item from the bookmarks menu or click on them in the bookmarks bar. But when I invoke them with an assigned keyboard shortcut (via System Preferences), they will open a new window (or new tab, respectively), effectively breaking the bookmarklet's functionality.

Reproducible: Always

Steps to Reproduce:
1. Add "increment link" bookmarklet to bookmarks
2. Assign shortcut in System Preferences
3. Back in Camino, open any webpage and press the shortcut assigned in step 2
Actual Results:  
Camino will open a new window or tab.

Expected Results:  
Camino will apply the bookmarklet on the currently displayed page.

I only tested this with the "increment/decrement link" bookmarklets:

javascript:function%20bookmarklet_to_do_num_add(){var%20e,s;%20IB=1;%20function%20isDigit(c)%20{return%20('0'%3C=c%20&&c%3C='9')}L=location.href;%20LL=L.length;%20for(e=LL-1;%20e%3E=0;%20--e)%20if%20(isDigit(L.charAt(e)))%20{for(s=e-1;%20s%3E=0;%20--s)%20if%20(!isDigit(L.charAt(s)))%20break;%20break;}++s;if%20(e%3C0)%20return;%20oldNum=L.substring(s,e+1);newNum=''+(parseInt(oldNum,10)+IB);while(newNum.length%3ColdNum.length)%20newNum='0'+newNum;%20location.href=L.substring(0,s)+newNum+L.slice(e+1);}bookmarklet_to_do_num_add();
javascript:function%20bookmarklet_to_do_num_sub(){var%20e,s;%20IB=-1;%20function%20isDigit(c)%20{return%20('0'%3C=c%20&&%20c%3C='9')}L=location.href;%20LL=L.length;for%20(e=LL-1;%20e%3E=0;%20--e)%20if%20(isDigit(L.charAt(e)))%20{for(s=e-1;%20s%3E=0;%20--s)%20if%20(!isDigit(L.charAt(s)))%20break;%20break;}++s;%20if(e%3C0)%20return;%20oldNum=L.substring(s,e+1);newNum=''+(parseInt(oldNum,10)+IB);while(newNum.length%3ColdNum.length)%20newNum='0'+newNum;%20location.href=L.substring(0,s)+newNum+L.slice(e+1);}bookmarklet_to_do_num_sub();

Comment 1

[Stuart Morgan]

This is a duplicate of bug 326823, but since it's framed specifically in terms of JS bookmarklets we could consider changing the bookmark loading to actually check for a javascript: scheme and handle that differently.

Comment 2

[Scheichi]

I see... so a workaround would be not to use the command-key in shortcuts... which somehow ignores the (original) intention of the command key (i.e. as a shortcut for a command), though. So, I do not agree with the WONTFIX status of bug 326823.

Since a bookmarklet (in the user experience) is not perceived as a bookmark, but rather as a command, Stuart's solution is a good solution, considering that the WONTFIX for bug 326823 won't be reconsidered any time soon. :-)

Comment 3

[Stuart Morgan]

(In reply to comment #2)
> So, I do not agree with the WONTFIX status of bug 326823.

If you have a workable technical solution for the general case that doesn't break the *vastly* more common use of the command key for opening bookmarks in new tabs, feel free to suggest it and we'll consider it.

Comment 4

[Chris Lawson (gone)]

(In reply to comment #1)
> This is a duplicate of bug 326823, but since it's framed specifically in terms
> of JS bookmarklets we could consider changing the bookmark loading to actually
> check for a javascript: scheme and handle that differently.

That seems like a fairly reasonable solution, especially since most of the bookmarklets I've seen act on the content of the current page and therefore "Open X in New" doesn't seem to have much meaning.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Not the same thing at all, and this a Camino UI bug, anyway.