Bookmarklet not available in Opera

[kelson]

When using Opera with WordPress 2.1, the link to the Press It! bookmarklet does not appear on the Write Post page. Copying the link from a Firefox window into Opera's bookmarks demonstrates that the bookmarklet code does work in Opera 9. (I have not tested the current bookmarklet with older versions.)

It looks like you're doing excessive browser sniffing in post-new.php, assuming (incorrectly) that Opera cannot handle the feature:

if ($is_NS4 || $is_gecko) {
...
} else if ($is_winIE) {
...
}

Since WebKit, Gecko, and Opera all work with the same JavaScript, perhaps a better way would be something like this:

if ($is_winIE) {
... 
} else {
...
}

Note for browser sniffing purposes: Beginning with Opera 9, Opera uses its own user-agent by default instead of spoofing MSIE or Mozilla. Neither $is_winIE nor $is_NS4 nor $is_gecko will fire. Example:

Opera/9.10 (X11; Linux i686; U; en)

[DD32]

Confirmed.
Line 56 of post-new.php:

<?php if ( $is_NS4 || $is_gecko || $is_winIE ) { ?>

It doesnt check for Opera in its allowed list. Should be changed to:
<?php if ( $is_NS4 || $is_gecko || $is_winIE || $is_opera ) { ?>

Patch file attached for svn
Milestone changed to 2.1.1 as its a validation bug

D

[DD32]

added new patch file.
followed suggestion to add opera to the gecko/NS4 bookmarklet.
Also re-enabled the support for MacIE, allthough it looks like that can be merged into the gecko/NS4 bookmarklet as well (as it uses the same javascript function to get selected text)

Although the idea of just sending different bookmarklets to WinIE and then another to every other browser seems workable, best that sniffing the browser is left in place asto prevent the bookmarklet being sent to browsers which cannot support it.

[kelson]

Re: leaving the browser sniffing in place: So what happens when another browser comes on the scene that's capable of running the bookmarklet, but doesn't trip the browser sniffing? Has anyone tried this in, for instance, OmniWeb, Shiira, or another WebKit-based browser that isn't called Safari?

Wouldn't it be more future-proof to check for support of getSelection and encodeURIComponent instead of looking at a browser's name?

[foolswisdom]

Replying to kelson:

Wouldn't it be more future-proof to check for support of getSelection and encodeURIComponent instead of looking at a browser's name?

That sounds like a great idea! If you are interested in doing the work please create a new ticket and attach the patch.

[DD32]

I posted an enhancement for the bookmarklet the other day here:
​http://trac.wordpress.org/ticket/3878
it *should* be cross-browser compatible, looking for feedback on it..

[johnbillion]

worksforme, Opera 9.10 on Windows XP.

[DD32]

Can you check what your User Agent is johnbillion?

User agent: Opera/9.20 (Windows NT 5.1; U; en)
is_NS4: 0
is_gecko: 0
is_winIE: 0
is_opera: 1
is_macIE: 0

It requires, NS4, Gecko, or winIE to be true for the bookmarklet to show.
Just tried a stock standard Opera 9.10:

User Agent: Opera/9.10 (Windows NT 5.1; U; en)
is_NS4: 0
is_gecko: 0
is_winIE: 0
is_opera: 1
is_macIE: 0

I find it hard to believe its working given those results.
Looking through the vars.php file, none of the browser detection scripts(besides opera) will match a Stock standard Opera 9.10 or 9.20(Nightly builds).

Despite that, The Opera bookmarklet cannot support getting the currently selected text. which Opera 8+ supports(from memory). Other browsers are also getting locked out of using the bookmarklet even if they could support it. Which is the main reason behind my new bookmarklet which supports all browsers which support JS: ​http://trac.wordpress.org/ticket/3878

[rob1n]

For 2.3, automatic JavaScript sniffing.

[westi]

Closing as invalid - there is no bookmarklet anymore