Closed
Bug 387264
Opened 18 years ago
Closed 17 years ago
javascript bookmarklets work from sidebar but not from Bookmarks menu
Categories
(Firefox :: Bookmarks & History, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jonathanbaron7, Unassigned)
References
()
Details
(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
Comment 1•18 years ago
|
||
Is this a regression?
Reporter | ||
Comment 2•18 years ago
|
||
(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•18 years ago
|
||
(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".
Reporter | ||
Comment 4•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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
Reporter | ||
Comment 12•18 years ago
|
||
(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•18 years ago
|
||
Perhaps something changed in Places that would have caused this?
Component: Bookmarks → Places
QA Contact: bookmarks → places
Comment 14•18 years ago
|
||
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.
Flags: in-testsuite?
Comment 16•18 years ago
|
||
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.
Keywords: regression
Comment 17•17 years ago
|
||
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?
Comment 18•17 years ago
|
||
neil, perhaps caused by bug 279703?
Comment 19•17 years ago
|
||
Does it work with the patch in bug 388280?
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Reporter | ||
Comment 20•17 years ago
|
||
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•17 years ago
|
||
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.
Reporter | ||
Comment 22•17 years ago
|
||
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•17 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Flags: in-testsuite? → in-litmus?
Comment 24•17 years ago
|
||
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
Status: RESOLVED → VERIFIED
Comment 25•16 years ago
|
||
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+.
Updated•16 years ago
|
Flags: in-litmus? → in-litmus+
Comment 26•15 years ago
|
||
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
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in
before you can comment on or make changes to this bug.
Description
•