The default bug view has changed. See this FAQ.

Browser should tolerate plug-in (plugin) malfunctions, like with a separate (own) process

RESOLVED FIXED in mozilla2.0

Status

()

Core
Plug-ins
P3
major
RESOLVED FIXED
15 years ago
4 years ago

People

(Reporter: rubydoo123, Unassigned)

Tracking

({dataloss, meta, topembed-})

Trunk
mozilla2.0
dataloss, meta, topembed-
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
blocking1.8.1 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL2:P1][Threading/Process])

(Reporter)

Description

15 years ago
meta bug to track the separation of browser and plug-ins
(Reporter)

Updated

15 years ago
Severity: normal → critical
Priority: -- → P2
Whiteboard: [PL2:P1]
Target Milestone: --- → mozilla1.0.3
(Reporter)

Comment 1

15 years ago
*** Bug 62460 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

15 years ago
Keywords: meta
(Reporter)

Comment 2

15 years ago
*** Bug 43106 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Blocks: 92997

Updated

15 years ago
Blocks: 58339
(Reporter)

Updated

15 years ago
Target Milestone: mozilla1.0.3 → mozilla1.1alpha
(Reporter)

Updated

15 years ago
Severity: critical → normal
(Reporter)

Updated

15 years ago
Priority: P2 → P1
(Reporter)

Updated

15 years ago
Keywords: meta
Summary: Meta: browser should tolerate plug-in malfunctions, like with a separate process → Browser should tolerate plug-in malfunctions, like with a separate process
Whiteboard: [PL2:P1] → [PL2:P1][Threading/Process]
(Reporter)

Comment 3

15 years ago
*** Bug 59653 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

15 years ago
Blocks: 74080
(Reporter)

Updated

15 years ago
Target Milestone: mozilla1.1alpha → mozilla1.2beta

Comment 4

15 years ago
This doesn't seem to be a truly meta-bug - there are no bugs this one depends on...
?

Comment 5

15 years ago
bug 58937 is related to this (though probably not blocked by it). beppe, had
time to look into this a bit more?

Comment 6

15 years ago
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed

Comment 7

15 years ago
Are we going to sign up for this? Beppe?
(Reporter)

Comment 8

15 years ago
Not for a while, we need to do a lot more digging than what we have up to this
point. We also need to understand how this could work across platforms.

Moving to future until we better understand the impact
Target Milestone: mozilla1.2beta → Future

Updated

15 years ago
Keywords: topembed → topembed+

Updated

15 years ago
Blocks: 176349
(Reporter)

Comment 9

15 years ago
The decision was to not do separate processing. Rather, at least on windows is
to follow the sub-classing work Andrei (169071). This bug remains open for Mac
and Linux work.

This would require extensive work from layout.

Removing topembed+
Keywords: topembed+ → topembed-
(Reporter)

Comment 10

15 years ago
reassign
Assignee: beppe → peterl

Comment 11

15 years ago
beppe: i'm not sure i understand bug 169071 and how that relates to this bug. 
would subclassing keep mozilla from crashing if, say, the quicktime plugin puked?

tia,
marc
(Reporter)

Comment 12

15 years ago
yes, that is exactly what it is supposed to do, the subclassing "wraps" the
plug-in as to insulate the browser application from bad calls, etc.

Comment 13

15 years ago
Structured exception handling with subclassing will only help crashes in the
window proc on Windows.

Since Quicktime usually crashes in another thread, that likely won't stop it
from bringing down the browser not to mention other plaforms.

This is a meta bug. There is lots of work that this would depend on, like
synchronization, plus lots of toolkit stuff to get the plugin to paint in the
browser and browser events to go to the plugin.

I was looking through the Windows Platform SDK lately and was wondering if
|SetUnhandledExceptionFilter| or |AddVectoredExceptionHandler| in XP would help
catch crashing in other threads?
Severity: normal → enhancement
Depends on: 68702
Keywords: meta
Priority: P1 → P3

Comment 14

15 years ago
*** Bug 185839 has been marked as a duplicate of this bug. ***
*** Bug 187469 has been marked as a duplicate of this bug. ***
*** Bug 193429 has been marked as a duplicate of this bug. ***

Comment 17

14 years ago
A bug in a plug-in can crash the browser.

All calls to entry points to plug-ins should be set up with signal handler to
intercept errors and terminate the plug-in function instead of allowing the
entire browser to crash.

A diagnostic should be displayed when a plug-in hits a fatal error.

As part of the test procedure to verify the browser operation, a set of
plug-ins, one for each entry point that can be called should be made.  These
plug-ins should make an illegal memory access.  The browser should not crash.

There are many bug reports in Bugzilla about plug-in's crashing the browser, but
 the fixes seem to be concentrating on the specific plug-in, instead of fixing
the common vulnerability in the browser.

Comment 18

14 years ago
> All calls to entry points to plug-ins should be set up with signal handler
> to intercept errors and terminate the plug-in function instead of allowing
> the entire browser to crash.
[...]
> As part of the test procedure to verify the browser operation, a set of
> plug-ins, one for each entry point that can be called should be made.  These
> plug-ins should make an illegal memory access.  The browser should not crash.

This will not protect Mozilla from a plugin that incorrectly overwrites valid
browser memory. The only way to get real protection from flaky plugins is to run
them in a separate process and have robust handling of the interprocess
communication channel on Mozilla's side.
Just my 2c.

Updated

14 years ago
Blocks: 176280
*** Bug 196046 has been marked as a duplicate of this bug. ***

Updated

14 years ago
No longer depends on: 68702

Comment 20

14 years ago
*** Bug 214596 has been marked as a duplicate of this bug. ***

Comment 21

14 years ago
is anybody actively working on this?
*** Bug 220568 has been marked as a duplicate of this bug. ***
*** Bug 240852 has been marked as a duplicate of this bug. ***
I mentioned in my bug that although Acroread isn't actually freezing, when you 
try to exit it, it brings up a dialog to the background asking you whether you 
want to exit. Therefore, it seems like it is freezing. Until you disable this 
dialog, you get the idea that Acroread is freezing Mozilla.

Comment 25

13 years ago
*** Bug 246484 has been marked as a duplicate of this bug. ***

Comment 26

13 years ago
Hopefully with the new plug-in interface (as announced here:
http://developers.slashdot.org/article.pl?sid=04/06/30/1258204) will not be
plagued by this issue.
I again had an issue with this bug. This time it was java_vm bringing down. Bug
102474 depends on this, as mentioned in
http://bugzilla.mozilla.org/show_bug.cgi?id=102474#c14
Blocks: 102474

Updated

13 years ago
Severity: enhancement → major
Keywords: dataloss

Comment 28

13 years ago
re: comment #26, it looks to me like the new stuff is just a set of extensions
to the old API and doesn't enforce separation of browser and plug-ins.  we're
still going to be stuck with this plague...

i don't think there's anything about the current API that keeps one from
separating the browser from the plug-in.  it's just a lot of work that nobody
with the requisite skills seems willing to take on.

Comment 29

13 years ago
*** Bug 270543 has been marked as a duplicate of this bug. ***
Summary: Browser should tolerate plug-in malfunctions, like with a separate process → Browser should tolerate plug-in (plugin) malfunctions, like with a separate (own) process
See also bug 230017

Comment 31

13 years ago
*** Bug 273602 has been marked as a duplicate of this bug. ***

Comment 32

12 years ago
*** Bug 280913 has been marked as a duplicate of this bug. ***

Comment 33

12 years ago
*** Bug 266653 has been marked as a duplicate of this bug. ***
*** Bug 290828 has been marked as a duplicate of this bug. ***

Updated

12 years ago
No longer blocks: 176280

Comment 35

12 years ago
*** Bug 176280 has been marked as a duplicate of this bug. ***

Comment 36

12 years ago
This would seem to need bug 242530 in order to maintain scriptability in a
general way.
No longer blocks: 58339, 74080
Depends on: 242530
*** Bug 294327 has been marked as a duplicate of this bug. ***

Comment 38

12 years ago
*** Bug 226843 has been marked as a duplicate of this bug. ***

Comment 39

12 years ago
*** Bug 242914 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Blocks: 200511

Updated

12 years ago
Blocks: 300756

Updated

12 years ago
Blocks: 253117

Updated

12 years ago
Flags: blocking-aviary2.0?
bumping to core noms
Flags: blocking-aviary2? → blocking1.8.1?

Comment 41

11 years ago
maybe moving the plugin to a external process, its possible, as we can see with this layer for x86_64 firefox being able to run x86 plugins

http://www.gibix.net/projects/nspluginwrapper/

for now this "proxy" isnt gpl, but (i hope) it will be in the future
at least the idea seens a good one to change as little as possible the plugin interface but still enable the plugins to crash (and like nspluginwrapper, enable x86 plugins support to other platforms)

Comment 42

11 years ago
> i don't think there's anything about the current API that keeps one from
separating the browser from the plug-in.  it's just a lot of work that nobody
with the requisite skills seems willing to take on.

Actually, through the current plugin API (unlike the Netscape 4 plugin API), you can get the Service Manager object, and from that, you can request a whole lot of possible XPCOM services. To replicate this environment in a separate process, we'll need bug 242520 fixed.

Comment 43

11 years ago
Bug 242530, you mean.

And yes, it's possible. I've done it on Linux. And RealPlayer does it on Linux, too, I believe. But doing it cross-platform with a scriptable plug-in is a whole lot of work without bug 242530.

Comment 44

11 years ago
What is "possible"? You can declare that the service manager and the DOM are not accessible to the plugin -- and simply not offer that feature to plugins anymore. Most plugins, which aim for compatibility with the lowest common denominator -- Netscape 4, Konqueror, Opera -- might still work, as they don't rely on the Mozilla-specific plugin goodies.

Comment 45

11 years ago
Anything's possible. I could conceivably implement code such as would resolve bug 242530 in my plug-in. It would be a lot of work and no other plug-in would be able to see the benefit. So, better that go in the browser.

Resolving bug 242530 would give plug-in developers the tools to create out-of-process plug-ins. But once that code is in place, it also becomes possible to move the plug-in harness itself out-of-process, which means *any* plug-in could be run out-of-process.

Comment 46

11 years ago
*** Bug 320696 has been marked as a duplicate of this bug. ***

Comment 47

11 years ago
*** Bug 333424 has been marked as a duplicate of this bug. ***
Not a blocker: too invasive for 1.8.1.
Flags: blocking1.8.1? → blocking1.8.1-
Assignee: peterl-bugs → nobody
QA Contact: shrir → plugins

Comment 49

11 years ago
*** Bug 334853 has been marked as a duplicate of this bug. ***

Comment 50

11 years ago
As a follow up to bug 334853, which has been marked as a dulicate...The attachment created during the crash seems to have been automatically deleted or something. Perhaps it has already been submitted to you somehow? But, I don't have it anymore.

Also, I've posted a related bug to the VLC developers if it is of any interest.
http://forum.videolan.org/viewtopic.php?p=61712
*** Bug 325512 has been marked as a duplicate of this bug. ***

Comment 52

11 years ago
*** Bug 250496 has been marked as a duplicate of this bug. ***
where does bug 230017 fit in dependencies?

Comment 54

11 years ago
(In reply to comment #53)
> where does bug 230017 fit in dependencies?
> 

But 230017 is about running plugins in another thread. It is a possible way to achieve the goal of this bug, but may not be a sufficient.

Comment 55

11 years ago
*** Bug 286717 has been marked as a duplicate of this bug. ***
Does XPCOM support anything equivalent to M$ COM out-of-proc servers, where the COM servers run inside a separate process, and the transfer of data between the interfaces living in the two processes in handled by COM (a process known as marshaling)?

If yes, then maybe this can be used to solve this bug?

Comment 57

11 years ago
It does not. That's what bug 242530 is about.

Updated

11 years ago
No longer blocks: 300756
*** Bug 350820 has been marked as a duplicate of this bug. ***
*** Bug 351473 has been marked as a duplicate of this bug. ***
*** Bug 345642 has been marked as a duplicate of this bug. ***
*** Bug 350146 has been marked as a duplicate of this bug. ***
*** Bug 352995 has been marked as a duplicate of this bug. ***
*** Bug 358885 has been marked as a duplicate of this bug. ***

Comment 64

11 years ago
Don't know if it helps, but here are the Event Properties of a such Firefox crash on WinXP:

Faulting application firefox.exe, version 1.8.20061.1023, faulting module jpinscp.dll, version 5.0.60.5, fault address 0x00007f3a.

It's a java malfunction, always at the same address.
Can someone check it?

Comment 65

11 years ago
lmocsi@gmail.com: this bug has a summary, it should be clear that your comment is not appropriate for this bug. find or file a different bug.

Updated

10 years ago
Duplicate of this bug: 322997

Updated

10 years ago
Blocks: 384115

Comment 67

10 years ago
Hi folks,

some time went by since anything happened here ...
I had a short look at nspluginwrapper. It's now under GPL and seems to compile
fine (not tested running it yet).

If it's stable, I dont see any valid reason not including it into mozilla and
replacing the current plugin loader by it.


BTW: for longer terms, using 9P2000 instead of the (not yet documented) 
socket protocol would make it more open and easier to handle. In the spirit
of Plan9 plugins so can rund virtually anywhere.


Comment 68

10 years ago
(In reply to comment #67)
> I had a short look at nspluginwrapper. It's now under GPL and seems to compile
> fine (not tested running it yet).
> 
> If it's stable, I dont see any valid reason not including it into mozilla and
> replacing the current plugin loader by it.

GPL license is not compatible for inclusion inside Mozilla (see http://www.mozilla.org/MPL/mpl-faq.html). But the author could still relicense it.

Updated

10 years ago
Duplicate of this bug: 401809

Updated

10 years ago
Duplicate of this bug: 403030
Duplicate of this bug: 405206

Comment 72

9 years ago
A related data point: Apparently since forever, Shockwave Player has suffered from a bug which causes it to randomly stop processing events (freezing the UI, but not the process) on multi-core computers due to a mis-implemented monitor. It can be worked around by setting the CPU affinity of Firefox to just one core. Should out-of-process plugins be implemented, a white/blacklist of plugin quirks would also be useful...

Updated

9 years ago
Duplicate of this bug: 448370

Comment 74

9 years ago
So, now Google Chrome is out and using a separate process for plugins. Not sure about IE8. This may become a hot topic.

Comment 75

9 years ago
Plug-in scriptability no longer depends on XPCOM; so this doesn't need to depend on bug 242530 anymore. (Which is not to say that XPCOM-based IPC is the wrong solution; just that it isn't obviously the right one.)
No longer depends on: 242530

Updated

9 years ago
No longer blocks: 200511
Duplicate of this bug: 457950

Comment 77

9 years ago
I'm not sure this bug is the appropriate place to put "Bug 457950".  I wasn't so concerned with a plugin crashing the browser (though that is a concern), I was more concerned that a plugin (Adobe flash) running in one window, wants to use all of the CPU.  That's fine.  I have 4.  But in a separate window, I am still "automatically" limited to only running on the 1 used processor.  I have 3 unused processors that can be used to browse or whatever -- but because the one window that's running flash is using such a high level of CPU, Adobe Flash keeps emitting error messages that a "script" (the flash script, I guess) is hogging the CPU (it is -- it's playing a hi-def movie that's barely being kept in sync -- probably a poor implementation by nbc.com), but I want to allow it to have its own CPU -- and keep browsing in *other* cpu's.  

When a plugin is using 80% of 1 cpu (as in my bug), the adobe flash player detects the high Cpu usage and high latency and brings up warning messages.  There isn't a CPU crisis -- it's just 1 cpu that's busy.  Why can't those plugins get a separate thread ?  Maybe __at least__ allow other WINDOWS to use other CPU's -- That's the bug.  When firefox is already using 100% of one cpu, it still blocks another instance of firefox from starting to run on another cpu.  It forces all windows to the same cpu.  

Why not make access to the profile protected with 'locks' and/or shared memory to hold a common state?  

This is the biggest value of Googles new browser over Firefox -- you can bet MS will have IE be multithreaded, but I saw Google's browser release being a direct competition to Firefox because FF is limited to 1 thread.  They are both open source -- they can both converge to a similar feature set -- but Google's browser isn't based on mono-threaded code so it can expand.  FF is stuck.
I could easily upgrade my system to eight cores -- but what would be the point?  I can't even make due with 4 cores, yet I am very often CPU bound in 1 core due to Firefox's stuck implementation.

In fact -- I don't require that the browser stay up if a plugin crashes -- that's far less common of an occurrence for me.  What is common is that every day, every FF window and tab are run in a small quarter-sized compartment in my computer because FF is so poorly written.

Why was it written as single threaded in the first place?  Seems like poor design from the start.  By default, code should be re-entrant and only non reentrant by special exception or necessity.  This has been a problem since the beginning, yet it keeps getting put off to some vague nebulous future.

What's the problem -- as even IE will supposedly run on separate cores (not sure if that was referring to future or now)?

But if bug 457950 doesn't require the browser to "not crash" when a plug-in crashes, is it really the same bug as this one?

Comment 78

9 years ago
Google is doing the right thing with Chrome, by putting every tab/plugin in its own process.  And Microsoft is doing the same in IE8.  Hopefully the Firefox team will come to their senses and do the right thing here.  This bug is 6 years old, so clearly this kind of user feedback isn't especially important to the Firefox team; hopefully pressure from the competition will be treated a little more seriously.

Comment 79

9 years ago
It is my sincere hope that when Google Chrome is completely open-sourced for all operating systems, the Chrome and Firefox teams can come to an agreement.

Firefox 4.0 = Combining the best features of Firefox 3.x and Google Chrome!

Top of the list would have to be this bug.  You can tell a lot of people want this feature, because it's among the top things Google Chrome advertises as being improvements.
(In reply to comment #77)
> I'm not sure this bug is the appropriate place to put "Bug 457950".  I wasn't
> so concerned with a plugin crashing the browser (though that is a concern), I
> was more concerned that a plugin (Adobe flash) running in one window, wants to
> use all of the CPU.

The issue is different from the user perspective, but the solution is identical: run plugins in their own process.  From a development perspective it's the same request.

Yes, you could solve your problem by using only threads, not processes, but that's unlikely to happen precisely because it doesn't solve the security problem, whereas using separate processes *would* help to solve the multicore utilization problem.

> There isn't a CPU crisis -- it's just 1 cpu that's busy.  Why can't those
> plugins get a separate thread ?

They can.  That's what this bug requests.  It will just take a considerable amount of development work.

FYI, this is not being ignored, IE8 and Chrome have gotten Mozilla talking about process-per-tab (and I guess -per-plugin too).  See some discussion here, at least on process-per-tab:

http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/06b9aade0a0ee360/830bbe3487eb91ae

But I get the impression that it's going to take a lot of work to implement.
Duplicate of this bug: 460527
Duplicate of this bug: 471327

Updated

8 years ago
Duplicate of this bug: 486636

Updated

8 years ago
Flags: blocking1.9.2?
There's work underway to do this, but it won't be done for 1.9.2.
Flags: blocking1.9.2? → blocking1.9.2-

Comment 85

8 years ago
If you want, I can test it using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090903 SeaMonkey/2.0b2pre ID:20090903004335 if you give instructions.

Updated

7 years ago
Duplicate of this bug: 533866
From what I noticed, nspluginwrapper installed by default even on non-64-bit, does this currently.

When Flash Player goes bye bye, Firefox is still working. Like in Opera, refresh is required to make it back.

Comment 88

7 years ago
Ah. Therein lies the confusion. The problem for me isn't that flash crashes; it's that flash is running (and that background tabs don't suspend it). Consider several windows with perhaps 50 tabs. Each of them may have an instance of the flash player. The firefox CPU usage hits 100%, firefox slows to a crawl, and the OOM killer eventually clobbers firefox.
Richard, you are introducing confusion into the matter. What you need in described situation is a flash blocking extension, like https://addons.mozilla.org/en-US/firefox/addon/433.

It will solve your problem completely.

This bug is about a significant architectural rework of Mozilla's browser plugin subsystem, regardless of whether we're talking about Flash, Java applets, or VRML renderers.

Updated

7 years ago

Updated

7 years ago

Updated

7 years ago
Duplicate of this bug: 538100
This bug is being worked on for a release that should come shortly after Firefox 3.6. That work is being tracked in bug 539055 / bug 531142.

Comment 92

7 years ago
There is another problem with it...
Enabling the separate process for the plugins in the latest trunk cause the plugins to freeze...
They just begins to execute, but after some seconds they just won't react!
This behaviour is with Flash Player (with nspluginwrapper) and mplayer-mozilla... Probably others also...

Comment 93

7 years ago
Evengard, it's not even alpha quality yet - that's why it's only available in the 3.7a1pre builds (nightly builds). You're probably seeing bug 542263 or bug 543303.

Comment 94

7 years ago
I don't think it is really those bugs, because turning it off the plugins works just fine...

Updated

7 years ago
Target Milestone: Future → mozilla1.9.3

Comment 95

7 years ago
This was fixed with the release of Firefox 3.6.4.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
To be clear, it's only partly fixed on Firefox 3.6.4:
 * only a specific list of plugins are out-of-process (silverlight, flash, and quicktime)
 * out-of-process support in 3.6.4 is only on Windows and Linux (not Mac)

However, on mozilla-central: 
 * all plugins are out-of-process
 * it works on Windows, Linux, and Mac

So based on the state on mozilla-central, the resolution in the previous comment that this bug is FIXED is correct, since bug resolutions reflect what's in mozilla-central.  The current situation on mozilla-central will hopefully be what ships in Firefox 4.

Comment 97

7 years ago
I'm running Firefox 3.6.6 on Linux (Kubuntu 10.04 64 bits) and it still freezes when flash freezes. All windows must be terminated when flash freezes.
Is the flash plugin loading through some file other than libflashplayer.so ?  

Because only libflashplayer.so is whitelisted (see comment 96).  The whitelisting happens through the line:
pref("dom.ipc.plugins.enabled.libflashplayer.so", true);
in defaults/pref/firefox.js (which, on Ubuntu, is in /usr/lib/firefox-3.6.6).

Comment 99

7 years ago
Thanks for the info, David. How do I verify that?
In about:plugins, I see:

Shockwave Flash
File: npwrapper.libflashplayer.so

Does this mean that the file through which flash is loaded is npwrapper, which is not whitelisted? Can I whitelist it? If yes, do I need to whitelist "npwrapper" or "npwrapper.libflashplayer.so"?

Thanks

Comment 100

7 years ago
marcelo, and everyone else:
Bugzilla is *NOT* a support forum.

please do not ask questions in resolved bugs.

for support, please visit http://support.mozilla.com

fwiw, you would have to whitelist the entire filename, not just some random substring.

Comment 101

7 years ago
timeless, the bug is not resolved for me in Firefox 3.6.6 and comment #96 says it should be starting in version 3.6.4. I'm trying to determine if the bug is indeed fixed or not.
I'm not asking general support questions.
Marcelo, the bug is fixed.  If there's a problem for you, it's most likely that the 64bit Linux installs which use a 32bit plugin wrapper for Flash are not whitelisted yet.

That smells strongly of a separate bug.  It may already exist, and it may really belong with Kubuntu/Ubuntu (which have packaged the flash plugin as such.)  If it's Mozilla's territory, and there's no bug yet, then you should probably file a new one depending on this or some such.

In any case, trying to determine how to use the about:config prefs for this is definitely support, so seems like that belongs where timeless said.

-[Unknown]
Target Milestone: mozilla1.9.3 → mozilla2.0

Comment 103

4 years ago
Bug 176280 was marked as a duplicate of this one (156493). For that reason, I'm reporting a new instance of that bug here. It's a bug where the Java fphover package causes infinite warning boxes.

I just experienced this problem again, many years after the previous report, when visiting www.chakraplein.nl/allin_taylor.htm. I am running Java 1.7.0 (the latest). Firefox 19.0.2, Windows XP Home SP3, computer otherwise running well. I have already also entered this info at bug 176280.

In my opinion, the problem should be fixed (in Mozilla) because it looks exactly like malware (a phishing attempt to get the user to click OK to gain access to install malware). If someone can replicate this report, I recommend it be fixed since it gives the appearance of being a serious bug (it isn't really a serious problem, but unsophisticated users may not realize that, because it makes the browser stop responding).
You need to log in before you can comment on or make changes to this bug.