387264 - javascript bookmarklets work from sidebar but not from Bookmarks menu

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[Jonathan Baron]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a7pre) Gecko/2007070705 Minefield/3.0a7pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a7pre) Gecko/2007070705 Minefield/3.0a7pre

I can open Ruderman's Javascript Shell (for example) from the Bookmarks sidebar, but not from the Bookmarks menu on the Menu bar.  Nothing happens when I click this item.  Other menu bar items work fine.


Reproducible: Always

Steps to Reproduce:
1. install Javascript shell as a bookmark
2. Click on Bookmarks, shell
3. Now open a bookmarks sidebar and click on it there.

Actual Results:  
works with sidebar, not with bookmark menu

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Is this a regression?

Comment 2

[Jonathan Baron]

(In reply to comment #1)
> Is this a regression?

I don't think so.  I've been using trunk builds for quite a while, and I use these bookmarklets a lot (especially shell).  I've never had this problem.  Note that, on one of my computers, I do not even use the sidebar with bookmarks.  The symptom I saw on that one was that shell would not work at all.  On the other computer, I tried the Bookmarks menu, that didn't work and then I tried the sidebar, and it worked.

I did notice one other thing.  For months, I would keep adding "shell" to the bookmarks and its name would not show up.  I would add its name by using "Properties," and then it would disappear the next time I started Firefox.  (I did not think that was worth reporting as a bug.)  Recently this got better.  The name is there.  But this was not true of the other bookmarklets.  And the present bug applies to all of them.  So I don't think this is relevant.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #2)
> (In reply to comment #1)
> > Is this a regression?
> 
> I don't think so.  I've been using trunk builds for quite a while, and I use
> these bookmarklets a lot (especially shell).  I've never had this problem.

I don't understand. If you've never had this problem, and now you're having it, then it would be a regression. That's the definition of a regression - "it used to work but now it doesn't".

Comment 4

[Jonathan Baron]

Oh.  Sorry.  Then it isn't a regression.  I misunderstood.  I am a psychology professor.  In psychology, "regression" means that something existed before (e.g., temper tantrums in childhood), got better (e.g., someone grew up and stopped having temper tantrums), and then it goes back to the earlier state (e.g., an adult has a childish tantrum).

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Ah, I see. You're right, that is the correct definition of "regression" (A->B->A, where A is a "buggy" state and B is the desired state). People (like me) tend to (perhaps erroneously) use it to mean any unintentional change in behavior B->A, where the original "A" might be the implied "before this software existed" or "before this feature was implemented". The fact that you haven't experienced the initial "A" state is usually not relevant to bug triagers :)

Comment 6

[Justin Dolske [:Dolske]]

Just noticed this today, although I don't use bookmarklets often. In my debug build console I get:

Security Error: Content at javascript:[...yaddayadda] may not load data from http://url.of.loaded.page

Comment 7

[Daniel Veditz [:dveditz]]

I think we mostly use the term in the way you describe in comment 4: a "regression testsuite" is a bunch of tests for previously fixed bugs intended to catch them should they come back ("regress").  But sometimes it's simply the opposite of "progression" -- we went backward, not forward -- used to distinguish "new" problems from ones that have been there all along. If we can pinpoint when a problem started we can find the change that caused it which can help tremendously in fixing it.

Comment 8

[Daniel Veditz [:dveditz]]

When I try to launch the Shell bookmarklet from the bookmark menu I don't get an error, but it gets blocked as a popup. Works fine when the bookmarklet is clicked on the personal toolbar though.

A debug build from 20070703 worked fine, so July 3-5 might be the regression window (don't count on that). Although I'm not seeing quite what's described in comment 0. I don't get the security error dolske saw, does the menu have about:blank context rather than chrome now?

Comment 9

[Daniel Veditz [:dveditz]]

CC'd bz because he changed a CheckLoadURI* call in nsContentUtils with bug 310165 in that date range. As I said I dont' see the error message dolske did, but that's a CheckLoadURI type message

Comment 10

[Boris Zbarsky [:bzbarsky]]

I can't reproduce this with my Firefox build pulled at MOZ_CO_DATE="Fri Jul 6 21:46:11 CDT 2007".  At least if I followed the steps to reproduce correctly.  Here's what I did:

1)  Load https://www.squarefree.com/bookmarklets/webdevel.html#shell
2)  Right-click on the button that says "shell" on it in green
3)  Select "Bookmark this link"
4)  Use the default if "shell" for the Name and click "Add"
5)  Click the Bookmarks menu
6)  Select the "shell" item
7)  In the resulting window, type "2 + 3" and hit enter

I get 5 as output.  Seems to be working...

Did something change in an interesting way in front-end land?  The difference between the bookmarks menu and the bookmarks sidebar (as well as the unexpected appearance of a javascript: principal, which means someone loaded things in a weird way) indicates that something could be up there.

Comment 11

[Justin Dolske [:Dolske]]

This is should recreate what I'm seeing. From a clean profile:

1) Drag "Linked Images" bookmarklet to bookmark toolbar. It's the 2nd one on https://www.squarefree.com/bookmarklets/pagelinks.html
2) Load http://people.mozilla.com/~dolske/testcase/387264/
3) Click "Linked Images" bookmarklet

...and, oh, hey, that works fine. But if you create a folder on the toolbar, and move the bookmarklet into it, then it fails with a "popup blocked" notification bar and the console error. Weird.

I didn't see the "popup blocked" bar originally, because I had set the pref to never show the bar.

I'll try this out on a clean 

Comment 12

[Jonathan Baron]

(In reply to comment #11)

> I didn't see the "popup blocked" bar originally, because I had set the pref to
> never show the bar.

I am still having the problem with Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a7pre) Gecko/2007071104 Minefield/3.0a7pre.
It is indeed a result of popup blocking.  If I turn off popup blocking, then it works.  (I too had the message about popups unset.) And I get a "Security Error: Content at javascript: ..." when it doesn't work.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Perhaps something changed in Places that would have caused this?

Comment 14

[Al Billings [:abillings - ex-MoCo]]

I'm using a Vox Bookmarklet with the url:

javascript:(function() {var s = document.createElement(%22script%22);s.setAttribute(%22src%22,%22http://www.vox.com/services/submit/link.js%22);document.body.appendChild(s);})();

I get a brief security warning for popups whenever I invoke it, which then dismisses itself with no interaction from me.

This is in  Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/200707120404 Minefield/3.0a7pre

I see it in the 2.0.0.4 release too though.

Comment 16

[pal-moz]

regress between 20070704_0524 and 20070704_0857 (Win build)

[range]
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1183551840&maxdate=1183564619

maybe no relation with Places, I think.

Comment 17

[Ivan Ičin]

This makes Furl and probably some other popular web services not work from bookmark menu. This should block Firefox 3 because of that IMHO.

Comment 18

[Dietrich Ayala (:dietrich)]

neil, perhaps caused by bug 279703?

Comment 19

[Neil Deakin]

Does it work with the patch in bug 388280?

Comment 20

[Jonathan Baron]

As of Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a7pre) Gecko/2007072304 Minefield/3.0a7pre, I notice that I can open the JavaScript shell either from the bookmarks menu or from the sidebar.  But the behavior is still different.  When I use the sidebar, it just works.  When I use the bookmarks menu, I get an indication that Firefox has blocked a popup.  (Unfortunately, when I reported the bug, I did not have this preference turned on, so I did not get any message about a popup being block.)  If I add the site to the exceptions for popup blocking, things work as they should.  Mostly I use this for local files, so what gets added to the list of exceptions is "scheme: file."  For me, this bug is now less serious than it appeared to be at first.  There is still a difference between the sidebar and the bookmark menu.  The bookmark menu thinks that the bookmarklet is a popup and the sidebar does not.  The difference would be a problem (I think) only for some who had the popup blocking notification turned off (as I did, for some reason) and who used the bookmark menu.

Comment 21

[pal-moz]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072323 Minefield/3.0a7pre ID:2007072323

seems to be fixed by bug#388280.

Comment 22

[Jonathan Baron]

I'm not sure I'd want to call this "fixed."  It means that you can't use javascript bookmarks that open a window unless you specifically list all the sites from which you might open them as exceptions to popup blocking (or unless you use the places sidebar set to show bookmarks ... or turn off popup blocking altogether).  It seems that there are lots of other useful javascript bookmarks aside from Jesse Ruderman's.  Some of these are surely useful on sites that you are visiting for the first time.  I think the old behavior of just allowing all popups from chrome (I think that's the term ... but I mean from the bookmarks menu) is better.

Comment 23

[Neil Deakin]

This is caused because command events from menus are now fired asynchronously which means that it no longer occurs during a user input event (mouse or keyboard). This caused the popup blocker to think that someone was trying to automatically open a popup. The fix in bug 388280 pushes the user input state onto the stack again.

Comment 24

[Paul Craciunoiu [:paulc]]

Wow it's been inactive for quite a while :)

Verified on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008060309 Firefox/3.0
and
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0

Comment 25

[Aakash Desai [:aakashd]]

Test cases 6092, 5943, 7452, 6852-6854, 6859-6860 and 6905 are already created for the 3.1 test run and 4134, 3985 5234-5236, 5242-5243 and 5291 for the 3.0 test run. Instead of updating each test case, I'm going to go ahead and flag this as in-litmus+.

Comment 26

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv