Could you comment in bug 425079 and attach your localStore.rdf, as described in comment 16? It would help a lot - we have a workaround fix, but we're trying to figure out the root cause.
Your explanation is slightly misleading. You don't need to "manually disable the popup blocker" to reproduce the popup opening part of the theoretical exploit. All you need to do is click "show popup [once]" option in the popup blocker UI for a blocked file:// popup.
That's wrong. This bug affects both 2.0 and 2.0.0.1. This confusion seems to stem from the version field in the bug, which is set to the earliest version that's affected.
Maybe because it's already fixed? Maybe because it's hardly a security issue? This is bugzilla bug 210658, it was filed in 2003, and fixed for 1.5 15 months later.
Slashdot Mirror
Could you comment in bug 425079 and attach your localStore.rdf, as described in comment 16? It would help a lot - we have a workaround fix, but we're trying to figure out the root cause.
Your explanation is slightly misleading. You don't need to "manually disable the popup blocker" to reproduce the popup opening part of the theoretical exploit. All you need to do is click "show popup [once]" option in the popup blocker UI for a blocked file:// popup.
That's wrong. This bug affects both 2.0 and 2.0.0.1. This confusion seems to stem from the version field in the bug, which is set to the earliest version that's affected.
Stop being a nerdy geek, would you?
Maybe because it's already fixed? Maybe because it's hardly a security issue? This is bugzilla bug 210658, it was filed in 2003, and fixed for 1.5 15 months later.
https://bugzilla.mozilla.org/buglist.cgi?query_for mat=advanced&short_desc_type=allwordssubstr&short_ desc=dhtml&resolution=FIXED&emailassigned_to1=1&em ailtype1=exact&email1=aaronleventhal%40moonset.net &chfieldto=Now