Last Comment Bug 432687 - (eviltraps) Protect users from websites that trap them or destroy their experience
(eviltraps)
: Protect users from websites that trap them or destroy their experience
Status: NEW
[sg:want]
: meta, sec-want, ux-control
Product: Core
Classification: Components
Component: DOM (show other bugs)
: unspecified
: All All
: -- critical with 49 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 416071 476593 481473 489531 519924 525812 555396 576030 577334 586022 648959 (view as bug list)
Depends on: 167475 186708 331334 334426 377496 380637 424201 502561 530258 578828 597934 598226 598246 602286 616838 675574 676975 678994 682565 682569 685828 705617 839470 861671 907634 947518 1003967 1125285 1131187 1167023 1173831 1208825 1208950 1234842 1238692 1241048 1246773 1263100 1270444 1272644 1276539 1278736 59314 alertloops 144069 backtraps 369608 391834 402401 450292 455078 458826 467536 CVE-2009-1828 481625 510185 559598 560767 564337 565541 578210 589166 599662 613800 616853 620615 635888 636374 636905 669107 748198 763257 808792 856977 909615 950336 CVE-2014-1500 1046022 1054966 1107771 1116977 1180976 1199934 1260612
Blocks: 550196 useragent
  Show dependency treegraph
 
Reported: 2008-05-07 13:30 PDT by Saïvann Carignan
Modified: 2016-07-05 11:27 PDT (History)
64 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Saïvann Carignan 2008-05-07 13:30:14 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9b5) Gecko/2008041515 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9b5) Gecko/2008041515 Firefox/3.0b5

There are javascript based websites that are traps which cause Firefox to show nasty content and stop answering user requests. Firefox behavior in these situations is really bad since it obey to the code and stop to listen to the user, it's not possible to close, change the configuration, close the tab or even exit Firefox!

A good example is this website (WARNING, this website shows pornographic content and you will not be able to close it without killing Firefox :

www.mylazysundays.com

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
Impossible to move/maximize/close the Firefox window, impossible to change the website, impossible to close the tab and impossible to modify the Firefox configuration.

Expected Results:  
Firefox should accept the user request to change the website or to close the website, and should not accept javascript code which cause Firefox main window to run on the screen and refuse the mouse.

Even if it's javascript, it's a major issue that Firefox refuse any user request in these conditions. There is no reason to justify the user losing control over Firefox.

Firefox should really give the possibility to the user to exit this webpage.
Comment 1 Jesse Ruderman 2008-05-07 23:15:54 PDT
This evil site does several things to get in the way of closing it:

* Tries to move the window around (bug 144069, bug 186708).

* Dozens of alerts in onbeforeunload (bug 391834 would prevent these from appearing; bug 59314 or bug 61098 would let you escape).

* Disables keyboard shortcuts such as Cmd+W.  Perhaps Firefox should not allow sites to cancel certain keyboard shortcuts.
Comment 2 Saïvann Carignan 2008-05-08 01:34:26 PDT
Then if this website use multiples bugs in Firefox which are already known and have a correct priority, I believe that this bug report should be closed, what do you think about it?
Comment 3 Jesse Ruderman 2008-05-08 01:46:18 PDT
Sure, it could be closed as INVALID, or it could be used as a metabug.  We should make sure there's a bug on the keyboard shortcut issue, too.
Comment 4 cmtalbert 2008-05-23 15:12:57 PDT
I like the idea of using this as a meta bug.  Transforming for that end.
--> Confirmed
--> Setting dependencies
--> And I'll file the follow on bug for the Cmd W redirect.
Comment 5 cmtalbert 2008-05-23 15:16:39 PDT
Added bug 435501 for the keyboard re-mapping issue.
Comment 6 dpk 2008-05-23 15:22:24 PDT
Clint, here's a bug for the keyboard re-mapping issue: bug 340902 (which was itself a duplicate of older bugs). It's marked resolved but I cannot personally confirm that it is a resolved matter.
Comment 7 - 2008-10-17 00:06:43 PDT
I just got tricked into visiting this website. Until now I never saw any purpose for the Noscript add-on, but Mylazysundays made me install it.

I still think Firefox should react on such infinite Javascript loops. For example, if a website shows a few alert windows, after three to five of them another popup should show up and ask "This seems to be an infinite Javascript loop. Do you want to abort it? [yes] [no, continue]".

This might be useful for computer illiterate people who have no clue how to use Noscript. Also, is there nobody who knows the webmaster personally to pay him a visit?
Comment 8 Daniel Veditz [:dveditz] 2009-02-03 08:38:52 PST
*** Bug 476593 has been marked as a duplicate of this bug. ***
Comment 9 Matthias Versen [:Matti] 2009-02-03 11:33:21 PST
*** Bug 476593 has been marked as a duplicate of this bug. ***
Comment 10 arimfe 2009-02-03 17:15:56 PST
google chrome and opera both deal with this issue perfectly.
chrome has a checkbox in the popup diaglog which prevents further dialogs to be created.
opera makes the user's "Close tab" command ABSOLUTE and it overwrites any javascript on the website.
Comment 11 funkydude87 2009-02-04 15:38:03 PST
Thanks

The fact that such problems have been around since 2000 with no fix is enough to kill Fx for me.

I will be dropping it and recommending Chrome as the safe web browser from now on.
Comment 12 Daniel Veditz [:dveditz] 2009-03-05 08:54:01 PST
*** Bug 481473 has been marked as a duplicate of this bug. ***
Comment 13 Mardeg 2009-04-22 02:30:22 PDT
*** Bug 489531 has been marked as a duplicate of this bug. ***
Comment 14 Paul Rubin 2009-09-12 23:34:58 PDT
Even blogspot is trapping the browser these days (onclose = "are you sure you want to navigate away from this page?", though at least it lets you exit). 

It is a bug that such an event even exists.  Closing a tab should "kill -9" the contents.  It should not post any type of event to javascript on the page or count how many alerts the page has popped.  It should just kill the page completely and instantly, along with all alert dialogs from that page.
Comment 15 u49640 2009-09-16 09:45:01 PDT
(In reply to comment #14)
> Even blogspot is trapping the browser these days (onclose = "are you sure you
> want to navigate away from this page?", though at least it lets you exit). 

Some of those Events should be ok. Like asking the user if he wants to save (submit) entered text on the page
(like a program asking if the user wants to save a file when it closes)

So the OnClose Event shouldn’t be kill −9, but more like kill −15 (SIGTERM). (but with an option to just „SIGKILL“ the page, like an app that doesn’t respond to SIGTERM)
Comment 16 Daniel Veditz [:dveditz] 2009-10-01 18:51:47 PDT
*** Bug 519924 has been marked as a duplicate of this bug. ***
Comment 17 Jesse Ruderman 2009-10-01 19:03:26 PDT
My rant about scareware in bug 455078 comment 5 might be relevant.
Comment 18 Daniel Veditz [:dveditz] 2009-11-02 12:18:50 PST
*** Bug 525812 has been marked as a duplicate of this bug. ***
Comment 19 Daniel Veditz [:dveditz] 2009-11-08 21:00:30 PST
*** Bug 416071 has been marked as a duplicate of this bug. ***
Comment 20 Jonathan 2010-01-26 22:04:54 PST
Safari by default warns you before closing a window where text is entered on a page.
Comment 21 Carlos Alén Silva 2010-02-18 21:03:19 PST
FWIW: I survive www.mylazysundays.com and similar sites thanks to AlertCheck https://addons.mozilla.org/en-US/firefox/addon/13176
This extension does something similar to what's proposed in comment #7 and Chrome's behavior cited in comment #10
Comment 22 Carlos Alén Silva 2010-02-19 11:59:08 PST
(In reply to comment #21)

Another extension that solves this problem: RightToClick: https://addons.mozilla.org/en-US/firefox/addon/12572
Comment 23 Matthias Versen [:Matti] 2010-03-27 09:48:11 PDT
*** Bug 555396 has been marked as a duplicate of this bug. ***
Comment 24 Nathan 2010-03-27 10:00:59 PDT
(In reply to comment #22)

A better fix, as the developers here don't seem to care:
http://www.google.com/chrome
Comment 25 Daniel Veditz [:dveditz] 2010-06-30 12:18:38 PDT
*** Bug 576030 has been marked as a duplicate of this bug. ***
Comment 26 philippe (part-time) 2010-07-07 18:39:30 PDT
*** Bug 577334 has been marked as a duplicate of this bug. ***
Comment 27 Matthias Versen [:Matti] 2010-08-10 12:12:40 PDT
*** Bug 586022 has been marked as a duplicate of this bug. ***
Comment 28 Kevin 2010-08-13 07:29:47 PDT
This bug should be resolved in Seamonkey.  I looked at NoScript and AlertCheck.  These are too unreliable or tedious, plus problematic updates. Who wants to spend hours learning how to secure a "secure" webbrowser?  I disagree with Comment 15.  Some kind of verify popup is fine in a program on the user's computer with the user's content, but in the context of the web, where the user does not have control over content, it should never be possible for the user to lose control of the program.  Secondly, if NoScript and AlertCheck can be written, then it should be possible for the developers to incorporate the same functionality.  I just hope something will be done.  Thanks
Comment 29 Biju 2010-11-20 17:59:04 PST
(In reply to comment #28)
We have bug 578828 for what your asking
Comment 30 Matthias Versen [:Matti] 2011-04-11 06:58:22 PDT
*** Bug 648959 has been marked as a duplicate of this bug. ***
Comment 31 Virtual_ManPL [:Virtual] - (ni? me) 2011-04-11 07:23:19 PDT
Awww, still not fixed...

Can't we temporary set to false default settings of dom.disable_window_move_resize in about:config like I mentioned in bug #648959 ?
Because with this option we have some control. Also Opera and Chrome behave that way too.
Comment 32 Virtual_ManPL [:Virtual] - (ni? me) 2011-04-11 07:25:32 PDT
(In reply to comment #31)
> Awww, still not fixed...
> 
> Can't we temporary set to false default settings of
> dom.disable_window_move_resize in about:config

I mean set it to true ;p
Comment 33 David [:auscompgeek] 2011-04-11 21:24:54 PDT
(In reply to comment #31)
> Awww, still not fixed...
> Can't we temporary set to true default settings of
> dom.disable_window_move_resize in about:config like I mentioned in bug 648959?
> Because with this option we have some control. Also Opera and Chrome behave
> that way too.

See comment 1. That pref also has a UI: Tools > Options > Content > Advanced button next to "Enable JavaScript". Popups should be able to resize and move themselves.
Comment 34 Virtual_ManPL [:Virtual] - (ni? me) 2011-04-12 00:55:30 PDT
Yep, I know, but this bugs are VERY OLD.
And pasting link to location bar and opening it isn't exactly the popup, because it didn't open any new window.

Opera and Chrome have this disabled as I see, so can't we do the same as workaround until some patch with detection of popups will land ?
This will prevent us for prank sites without option to close tab/window, because keyboard shortcuts are disabled and all application running from mouse pointer.

Odd, that it's still not fixed ;p
Comment 35 Adam Muntner [:adamm] (use NEEDINFO) 2013-08-27 12:37:53 PDT
Can someone who is more familiar with firefox internals than me comment on 

https://bugzilla.mozilla.org/show_bug.cgi?id=909615#c10

please?

In particular, the user's comment, "The problem is that Firefox works in a totally unexpected way. The user clicked on the tab close button and when a confirmation dialogue appears he expects that this is for confirming the tab close action. I don't see any valid reason for Firefox to disrespect the users wish in this regard. I would be a different thing if the user asked to just close a specific (i)frame but I don't think that Firefox even allows that?"

Note You need to log in before you can comment on or make changes to this bug.