Closed Bug 387264 Opened 15 years ago Closed 15 years ago

javascript bookmarklets work from sidebar but not from Bookmarks menu


(Firefox :: Bookmarks & History, defect)

Not set





(Reporter: jonathanbaron7, Unassigned)




(Keywords: regression)

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
Is this a regression?
(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.
(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".
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).
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 :)
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
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.
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?
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
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
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.
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
2) Load
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 
(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.
Perhaps something changed in Places that would have caused this?
Component: Bookmarks → Places
QA Contact: bookmarks → places
I'm using a Vox Bookmarklet with the url:

javascript:(function() {var s = document.createElement(%22script%22);s.setAttribute(%22src%22,%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 release too though.

Flags: in-testsuite?
Duplicate of this bug: 388123
regress between 20070704_0524 and 20070704_0857 (Win build)


maybe no relation with Places, I think.
Keywords: regression
This makes Furl and probably some other popular web services not work from bookmark menu. This should block Firefox 3 because of that IMHO.
Flags: blocking-firefox3?
neil, perhaps caused by bug 279703?
Does it work with the patch in bug 388280?
Flags: blocking-firefox3? → blocking-firefox3+
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.

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.
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.
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.
Closed: 15 years ago
Resolution: --- → FIXED
Flags: in-testsuite? → in-litmus?
Depends on: 388280
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
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0
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+.
Flags: in-litmus? → in-litmus+
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.

Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.