Closed Bug 167559 Opened 22 years ago Closed 22 years ago

New popup management improperly blocks some popup alerts/prompts.

Categories

(SeaMonkey :: Preferences, defect)

Product:
SeaMonkey
Component:
Preferences
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.2beta

People

(Reporter: 3.14, Assigned: bugs)

References

(
URL
)

Details

(Keywords: qawanted)

Attachments

(1 file)

Testcase - initial unrequested popup alert is blocked.
463 bytes, text/html
Details 
Happening in latest-trunk Linux and Windows.

If you have dom.disable_open_during_load disables true, window.alert will not
work. This is unexpected and IMHO a bad thing. There is use of alert/prompt
windows while I still don't want popups.

Note, it also happens for bookmarks like this:
javascript:location.href=%22http://groups.google.com/groups?as_umsgid=%22+window.prompt('Message-ID?');

pi
How is an alert any different from a popup?

cing danm because I'm not sure how his changes affect this.
  Good guess, cc:ing me.
Assignee: joki → danm
I did this intentionally. I don't see the distinction between popup windows and
popup alerts, except that popup alerts are even more annoying, being modal. I
think they want to be under the same sort of control as other, less annoying
windows.

Sadly, alert control is going to be lost when I check in the patch for bug
166442. So Boris will be happy on that day, but I think we should revisit that.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Target Milestone: --- → mozilla1.2alpha
To answer Boris' question: An alert window belongs to another window, it is not
a new one. So the wording of the preferences is completely missleading. An alert
can give additional information while not being abused for commercials. I have
seen it in a homebanking application.

Further, a prompt can ask for useful information, see my example above which is
a workaround for the bug that Mozilla does not understand message-ids. So those
kind of things are more useful than harmful. Therefore I ask you to rethink you
decision.

Maybe related (I haven't found the bug for that yet), disable_open_during_load
also blocks wanted windows (opening when clicking a link), see e.g.,
http://p2night.tv/ and click on contact.

pi
> How is an alert any different from a popup?

I just discovered this annoying new "feature" myself.  I sometimes use Imp (a
Web based interface to email) when not at home to use my regular email client. 
In Imp, I set it to pop up an alert window whenever I get new email - this is
something that I've found quite useful.  But with the recent change, I am no
longer notifed when new email arrives because the alert is ignored.  I certainly
do not want to see popup windows, but I definitely *DO* want to see popup
alerts.  The recent change in code is, also IMO, a "bad thing".

> Sadly, alert control is going to be lost when I check in the patch
> for bug 166442.

Are you saying that the fix for bug 166442 will allow popup alerts again (but
not popup windows) if that's what the user chooses?  (You say that alert control
will be lost - but this seems odd since it's *already* been lost by the code
change...?)
How about having 2 different prefs, one for windows, one for alerts? I as well
have seen useful alerts, dont remeber where though...
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Personally, I don't think that alerts/prompts should be made part of
"open_during_load" at all - that's a mis-categorization.  Alerts are created in
already existing windows, normally after they've been around for a while.  They
"alert" somebody to something that's happening with a window that they've
already expressed an interest in (by explicitly visiting it).

If somebody thinks that alerts/prompts should *also* be suppressed then it
should be addressed in a separate bug.  (And, yes, I agree that a separate pref
here, as per comment 6, is appropriate if any kind of suppression is to be done
at all.) Note that alerts/prompts have not been suppressed until very recently,
and I think that the sentiment against it, from those who find them beneficial
and have used them, is a good indication that they are not the same as popups.
(Boris, comment 4): >an alert can give additional (useful) information

This doesn't make alerts special. A non-alert popup window can also give
additional useful information. I continue to be unable to see any distinction
between popup alerts and popup windows, other than popup alerts are ten times
more annoying because they're modal.

(Jason, comment 5, comment 7:) Yes, starting this morning, alerts and prompts
are no longer affected by popup window management. It's a shame because alerts
are TEN TIMES more annoying than a normal popup. Have I mentioned that they're
even more annoying? A whole lot more annoying? The issue here is "what can an
unscrupulous website author jerk do to force my attention where I don't want it,
and what can be done to quell that?" You folks want to skate closer to the edge
than I do.

(Vladimir, comment 6:) What is best in life? Crush your enemies, see them driven
before you, hear the lamentation of their women and add more prefs to Mozilla.
Sounds like we're going to do at least one of those.

There's a new prefs panel coming. See bug 166442 comment 25. You guys want to be
sure your option makes its way into that. I'm going to morph this bug rather
than make a new one, because I'm lazy and because most of this bug is discussion
useful to its new mission.
Assignee: danm → jglick
Status: REOPENED → NEW
Summary: disable_open_during_load disables window.alert and window.prompt → distinct controls for popup windows and alerts wanted
Target Milestone: mozilla1.2alpha → mozilla1.2beta
> It's a shame because alerts are TEN TIMES more annoying than a normal popup.

Perhaps (see next paragraph).  But ever since the original popup blocking was
introduced, I can't recall running into a popup alert that annoyed me - my only
memories of popup alerts are those that I've appreciated.  Whereas, prior to 
blocking, and when I've temporarily disabled it or been exposed to them when
having to use IE, I *know* I've constantly run into annoying normal popups.

They *may* be ten times more annoying (although I'd dispute that since the
window size is a lot smaller than that of a regular popup window and it's just
as easy to click on OK as it is to close a window) when they occur, but they're
encountered, let's say, less than one hundredth of the time - and I think I'm
being far too liberal there.
Moving to preferences, this is not DOM Events
Component: DOM Events → Preferences
I agree with Jason. Alerts are not abused for commercials (and I have no idea
how they could). Prompts ask for information. Not entering makes pages/links
useles (see my original example). Also I gave the example of homebanking where
alerts warn you about modifiactions made to your order depending on market
specifications.

Certainly, it is a valid request to block them, but this is different from popups.

pi
Summary: distinct controls for popup windows and alerts wanted → distinct controls for popup windows and alerts/prompts wanted
Blocks: 166442
Just marked this one as blocking bug 166442.  The blocking direction is a
*little* "chicken and the egg" but I'd say that this bug should introduce the
backend preference for alert popups, while bug 166442 introduces the frontend
UI.  This one can be resolved fixed once the other bug's UI is sufficiently
changed for it to be presented to users.
Alerts are used within pages for info all the time: "Are you sure you want to
delete your order? OK/Cancel"

Code: if (window.confirm("Are you sure you want to delete your order?")) then...

I can see how you could stick text ads in them, but they are needed.
*** Bug 168955 has been marked as a duplicate of this bug. ***
Since we have a target milestone 1.2b, what can we expect? And when?

pi
*** Bug 170348 has been marked as a duplicate of this bug. ***
I have seen a website (norwegian student site: www.studweb.no, closed for other
than students), that is using javascript-alert for all error messages! It almost
unusable without these "popups". 

Also there might be another bug! See my duplicate Bug 170348, which tells that
it is actually possible to have the alert box in 1.2a when including the
type-parameter of <script>, with "open unreq" off.
(1) I *heavily* use alerts while developing / debugging JavaScript code ...
suddenly I thought something was "horribly" wrong with my installations and my
code (duh).  It is akin to Trace() in Flash and printing to standard out or the
console in other programming environments. I realize this is a developer's
concern, not a joe average concern.

(2) confirmations, errors and other items PROVIDE DIFFERENT FUNCTIONALITY
frequently than a POP-UP WINDOW does.  They just aren't the same thing.  While
I'm not happy about a new preference either, I just want to cast my vote that
the minute I found this I was distresses and suddenly found myself TURNING OFF
pop-up blocking, which was previously my new fave feature (except tabs) in Mozilla.

Suddenly I'm not going to be told by my bank that my OnLine Banking session is
about to time out, simply because I have pop-up blocking enabled?

Reviewers everywhere are all over pop-up blocking -- they love it. I think that
altering the functionality of this feature should be done carefully. 
Potentially a useful feature is now a troubling one.

Regardless of the "annoying" nature of the alert (which I might concede) in the
wrong cases, I don't think they're the same thing and therefore should not be
treated as the same thing. Plus, you're changing an existing feature.

I think those that share this opinion need to watch bug 166442 carefully.

:rob


--> default owner.
Assignee: jglick → ben
QA Contact: vladimire → sairuh
Summary: distinct controls for popup windows and alerts/prompts wanted → distinct controls for popup (unrequested) windows and alerts/prompts
Popup windows are blocked only at OnLoad, but the alert-blocking applies to all
alerts. That is very unexpected (and for me unwanted) behaviour.
  Anca: alerts are definitely not /completely/ disabled. Something else must be
going wrong on your build.
  The good news is, the new popup window manager doesn't control alerts. Use it
instead of the Advanced pref and you'll get all the alerts you can stand.
> The good news is, the new popup window manager doesn't control alerts.
> Use it instead of the Advanced pref and you'll get all the alerts you
> can stand.

Unfortunately, this is not the case.  I have checked (allowed) "Open unrequested
windows" under Advanced, and checked (disallowed) "Reject pop-up windows" under
Popups.  If the above were to work, I would once again be getting my "New Mail"
popups when using Horde/Imp.  But I do not.  Only by allowing *all* popups (even
with the new popup manager) do I get these alerts again.

I'm still waiting for some method of blocking annoying popup windows without
also blocking needed alerts...
*** Bug 172623 has been marked as a duplicate of this bug. ***
Is this new pop-up manager supposed to work already? On one test page, it did
nothing in my build. On the pop-up test page I used, all banners got displayed,
regardless what I selected in the new pop-up preference screen (disabling all
did nothing). Only disabling unrequested windows at the advanced JavaScript
options blocks them.

However, whenever I enable pop-ups in the new preference screen, "open
unrequested windows" is enabled automatically (is this intentionally?). But when
selecting to not display pop-ups in the new pref menu, "open unrequested
windows" is not disabled again. So these are not the same setting in fact,
right? This is confusing, the advanced settting should be removed if the new
pref tab takes over this task.

Also check the following page:
http://www.guardwall.com/English/GuardIE/tests/popups.asp

Mozilla can't block pop-ups that open on mouse-over, so by just moving your
mouse over a link, a pop-up may open (as can be tested on this page) and this
can't be blocked so far (without disabling JS or disabling the window open()
function in general).
*** Bug 174279 has been marked as a duplicate of this bug. ***
Keywords: qawanted
QA Contact: sairuh → paw
Jason (comment 22): could I see a Horde/Imp code sample? If I do as you
describe, (check advanced > scripts > open unrequested windows) and (select
privacy > popups > reject popup windows) then this page

<html><head>
<script>
function popupwin() {
  setTimeout("open('about:blank', '_blank')", 10);
}
function popupalert() {
  setTimeout("alert('boo')", 10);
}
</script>
</head><body>
<a href="javascript:popupwin()">open popup window</a><br>
<a href="javascript:popupalert()">open popup alert</a><br>
</body></html>

works as expected. popupwin fails, but popupalert succeeds.

tgos (comment 24): for a description of the two competing popup window prefs see
bug 166442 comment 64 - 70, especially comment 65 and also 87. Yes it's an
unnecessarily complicated UI. I'd like to simplify it some day but myself, I
won't be able to get to it before 1.2b ships.

Yes, Mozilla can't block mouseover popups. We haven't figured that one out yet.
I hope it doesn't become important any time real soon. However except for bug
173016 which I also can't work on right now popup blocking is known to generally
work. Could you pin down what your uncooperative test page is doing that defeats
us? If it's not a known problem, that being mouseover popups or something
covered by 173016, please file a new bug.
Horde/Imp code is simple enough:

<script language="JavaScript" type="text/javascript">
<!--
if (confirm('<?= addslashes(_("You have new mail in the following folder:")) .
"\\n$alert" . addslashes(_("Do you want to open that folder?")) ?>')) {
    window.location.href = '<?=
Horde::applicationUrl('mailbox.php?newmail_popup=no&mailbox=' .
urlencode($mailbox_message), true) ?>';
    window.focus();
}
// -->
</script>
With some further investigation, I can confirm that the JavaScript from comment
26 works appropriately.  (The window is blocked but the alert is not.)

However, it seems that only alerts that are called as part of a *function* are
allowed through.  If alert("x"); is used directly, outside of a function, then
it will be blocked.  (Only if all popups are allowed can the "raw" alert(); work.)
After even more investigation: JavaScript alert(); code only fails to be allowed
through when it is contained within a <script></script> block and outside of a
function wrapper.

I'm attaching an actual testcase here.  If it were to work properly, what would
happen is that loading the page would immediately result in an unrequested popup
alert, then you'd see 3 links.  The first, to a popup window, would be blocked,
while the other two popup alerts would be allowed through.  When I load the page
I never see the first unrequested popup alert - it's blocked - but the remaining
links work as they should.
This is very bad.  Alert() and promopt() should NOT be considered the same as a
pop-up, and will cause a lot of broken sites (form validation alert() telling
you that you didn't enter info for example).
  Ah! Now I see the problem. It's an interesting timing issue, the naked
<script> block alert running as it does before the chrome document has finished
loading. Note that only naked alerts in <script> blocks are blocked. Alerts in
load handlers are not.
  Yeah, we need to get this all cleared up. The patch in bug 173016 (with a
small addition) will fix this problem, too. Sadly, I am not allowed to work on
this right now. I'll get it fixed as soon as I can.
  Actually, once bug 173016 goes in, *this* bug will be moot. Alerts will be
exempted from the popup block check. And of course with no implementation, there
will be no UI for that either. If we re-enable alert blocking someday, we'll
need to add a UI. But there's no plan for either.
Depends on: 173016
> Actually, once bug 173016 goes in, *this* bug will be moot. Alerts
> will be exempted from the popup block check.

Actually, I'm not sure about that.  This bug isn't about always allowing alerts
and prompts, but for having distinct control over them (at least that's what the
Summary and comment 6 imply, if not comment 0).  While I, personally, wish to
always see them, there might be some people who don't want to ever see them. 
The recent beviour of some being blocked might, in some sense, be considered a
regression (and should obviously be corrected) but it's not actually the final
solution to this specific bug which is about having something along the lines of
an "[ ] Allow or deny alerts/prompts as per popup blocking." - at least, that's
how I interpret it.  I could be completely wrong.  It's happened before.

Other opinions?  Once popup alerts/prompts are ALWAYS allowed again - is this
bug still open?  Boris?
Jason: then you'd want to morph this bug or better yet, open a new one. A
feature request to add alert blocking and while we're under the hood, make it
configurable. There's no point in adding an alert blocking UI because there's no
implementation. There's no plan to add an implementation.
This bug is open in build 2002101617. Just try the URL above.

pi
Okay.  Based on comment 34, I am changing the Summary of this bug (still in line
with comment 0) in order to clarify what this particular bug is about.

If distinct and configurable UI controls for alerts/prompts are wanted *in
addition* to not blocking alerts/prompts (see comment 6) a new enhancement bug
can be opened for that.

Boris: Hopefully this is okay with you.
Summary: distinct controls for popup (unrequested) windows and alerts/prompts → New popup management improperly blocks some popup alerts/prompts.
Maybe it would be better if a new option called "Disable popups for this site"
was added so that one may choose to only disable those coming from ad sites
(i.e. doubleclick.net, etc...)  The feature would work similar to the "Never for
this site" option in the Password manager.
This bug still seems to be about blocking alerts, not an RFE to make alert
blocking configurable. See comment 36. Well then. Alerts are no longer blocked.
Marking fixed. If anyone wants to make an RFE for alert blocking, please open a
new bug; don't morph this one.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
I agree with the resolution of this bug (and comment 38) - at least for the most
part.  However, I have to point out that it was not actually fixed in the sense
that it or bug 173016 were changed in any way.  The only thing that's been
"fixed" is the symptom here - not the cause.  The backing out of the new popup
blocking management system is acknowledged as only a temporary measure for
Mozilla 1.2 final.  Once 1.3 alpha checkins are allowed I'm assuming that the
new popup blocking management will be hooked back in again.  At that point, this
bug (and bug 173016) will be back in full force.

Since this bug is already marked FIXED (technically it should really have been
marked WORKSFORME at this point) I will not force the issue and reopen it now -
but I can pretty much promise that as soon as bug 166442 is hooked up again I
will be reopening this bug because the symptoms will immediately re-manifest
themselves...
No, this one is fixed -- we made code changes in the back end that were causing
this. Any new popup blocking UI in 1.3 will be using blocking in nsGlobalWindow
(back-end checked in) rather than nsWindowCreator -- the alert blocking problem
will not be coming back.
Oh, my mistake - and apologies for any noise.  I'm still confused though.  You'd
said in comment 32 that a fix for this bug would be based on getting bug 173016
fixed (and this bug is still marked as being dependent on it) - yet no progress
has been made in bug 173016 since that statement nor have there been any other
comments in this bug about any other related bugs.

What bug was it that was recently resolved (or had code checked into it) that
solved this one but not (finally) bug 173016?  Or was code checked in that
wasn't, somehow, related to any bug (if that's possible) but that somehow
"collaterally" solved this one?  Essentially I'm confused by the seemingly
contradictory statements of comment 32, bug 173016 comment 17, the fact that
this bug has been marked FIXED while bug 173016 has not (and will admittedly
probably be returning) and a lack of any reference in this bug, bug 173017, or
bug 166442 of new code that's been checked in anywhere recently...

In any case - removing this bug as blocking bug 166442 (it no longer makes any
sense now that we've resolved the scope of this bug) and removing the dependency
this bug has on bug 173016 (if this one is fixed it obviously doesn't depend on
that one).
No longer blocks: 166442
No longer depends on: 173016
When a complete fix for bug 173016 was checked in it would also have fixed this
bug. However the applicable parts of that fix were instead checked in as part of
the fix for bug 174765.
Ah!  This all (sort of) makes sense with that piece in place.  I'll put down my
pen and walk away from this.  First, though, let me thank you for the great work
you've done in all of this.
*** Bug 179075 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021108 (+ patches
101274, 101762)

Verifying as reporter.

pi
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: