From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0.0+) Gecko/20020505 BuildID: 2002050508 Through Bug #126224 the pref dom.disable_open_click_delay was introduced. This has no UI at this time but i activated it in the prefs.js (user_pref("dom.disable_open_click_delay", 10);) and all popups are gone. The problem is, that since this the bookmarklets I'm using also stopped working. To get it working again I raised the delay to 1000 ms. But now some popups appearing again and I've to run quite fast when using the bookmarklets to klick it within one sec after selecting a word. The second way to use the bookmarklet via run it, insert the word to search for in the dialoge (called via prompt) and go does never work. Reproducible: Always Steps to Reproduce: 1. Set above user_pref (delay can be higher since I've 1000 now). 2. Visit http://www.worldtimzone.com/bookmarklets/mozbugs.php 3. Add Bookmarklet "Go to Bugzilla (Opens in New Window)" to your Personal Toolbar Folder 4. Klick on the Bookmarklet, enter a keyword and hit OK 5. Select a word from on a webpage and klick on the Bookmarklet within the delay given in the pref 6. Select a word from on a webpage and klick on the Bookmarklet after the delay given in the pref Actual Results: Step 4: nothing Step 5: page opens with results Step 6: nothing Expected Results: see result to step 5
To rginda.... Not sure how we're determining when the last click was, here.. Which particular bookmarklet is being problematic?
Assignee: joki → rginda
> Which particular bookmarklet is being problematic? No particular, every bookmarklet that wants to open a new window in general (I have three different in use) when dom.disable_open_click_delay has been set. A good example is the one mentioned (see Step 3, the second one on the site) on the mentioned site (Step 2).
http://bugzilla.mozilla.org/attachment.cgi?id=73206&action=view There is the patch that introduced the pref. We record the time of the last mouse click, and subtract it from the time window.open is called.
> We record the time of the last mouse click, and subtract it from the time > window.open is called. And? That seems nice and easy and protect users from being sued by popups. But it keep other code, code the user wants to be executed, from working. I see the problem and have no idea what to do else but want to show that the patch applied is everything else than trouble-free.
So... The problem is an interesting one. This could affect not just bookmarklets but other JS as well.... Consider the following situation: 1) User clicks on button 2) JS puts up a prompt() asking the user for information 3) User takes some time to fill in the textfield, then clicks or hits enter 4) JS attempts to window.open(), but the last click was before the prompt() was posed, which is too long ago. This is step #4 in the reproduction scenario in comment 0. Step #6 is the following: 1) User highlights word (this is a click) 2) User clicks bookmarklet. This is not considered a click on the page (imo this is a problem in itself). So nothing happens. Confirming that these are both problems; whether we want to try and fix them is a separate issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 95 → All
Hardware: PC → All
Also, I suspect that this pref also makes things fail if a user triggers a link with the keyboard and that link calls window.open()
> Also, I suspect that this pref also makes things fail if a user triggers a link > with the keyboard and that link calls window.open() Interestingly this isn't the case (just tested). But I don't believe this awareness could help to solve the main problem. In <a href="#c5">comment 5</a> you're right, this could affect every JS code that first calls prompt(). > User clicks bookmarklet. This is not considered a click on the page (imo > this is a problem in itself) It's a problem in itself? I'd say if Mozilla would consider this click as one to reset the timer, half the problem is gone. Remains the prob of the interruptive prompt().
Seems to work for me on build 2002-12-30-02-trunk, has this issue been resolved?
No, can't confirm this with 2002123108. Same behaviour as the previous versions show.
You need to log in before you can comment on or make changes to this bug.