69292 - popup blocking works too well

Status: VERIFIED WORKSFORME

(Bugzilla :: Bugzilla-General, defect)

Description

[Cesar Eduardo Barros]

The bugzilla helper uses a popup. This is not a problem, UNLESS you enabled
popup blocking. I think the helper should be redesigned to allow it to work
without having to open a new window.

Comment 1

[Stephan Niemz]

The helper is part of the Mozilla web pages, not the Bugzilla code,
so reassigning to mozilla.org.

Comment 2

[Stephan Niemz]

really reassigning this time

Comment 3

[Jacob Steenhagen]

Gerv handles bugzilla-helper.

Comment 4

[Gervase Markham [:gerv]]

The problem here is that, AIUI, Mozilla currently doesn't remember the form 
contents from previous forms in the history. So, if the new info opened in the 
same window, you couldn't go "back" to change stuff. If Bugzilla was down, you'd 
have just lost all your bug report.

I could get it to check for popup blocking and open in the same window if it's 
turned on, if someone can tell me how to tell the difference. I suspect it's 
something to do with the return value of the window.open() call or somesuch.

Gerv

Comment 5

[Gervase Markham [:gerv]]

I've worked out how to detect when popup blocking is working - catch the 
SecurityException - but I can't work out how to adapt the code which opens a new 
window, writes a form to it and submits it, to make it modify the current window 
instead.

How does one get a [object Window] representing the current window?

Gerv

Comment 6

[Justin H.]

If nobody ever answered this, can't you use this.window (assuming you're using 
javascript calls).

Comment 7

[Gervase Markham [:gerv]]

I still can't work out how to adapt the code which opens a new window, writes a 
form to it and submits it, to make it modify the current window instead. I need 
some way of clearing the current window of all its content - nuking the entire 
content model. Anyone got any ideas?

Gerv

Comment 8

[Justin H.]

Attachment: Current vs. new - hope it helps

Comment 9

[Gervase Markham [:gerv]]

Now I've run into the problem that Netscape 4 doesn't like try/catch blocks,
which I need to use to catch the security exception. <sigh>.

Gerv

Comment 10

[Justin H.]

I'm afraid you lost me.  What security exception?

Comment 11

[Gervase Markham [:gerv]]

The one Mozilla throws when you try and open a new window when popup blocking is 
enabled.

Gerv

Comment 12

[Justin H.]

Then the only solution I can think of is to wrap the throw/catch section in 
something similar to this:

if (document.getElementById) {
  code here....
}

The only downside being that certain versions of OE will run that code.

Since I'm not that good at browser detection, you might want to ask Martin 
Honnen for a second opinion.

Comment 13

[Gervase Markham [:gerv]]

*** Bug 94884 has been marked as a duplicate of this bug. ***

Comment 14

[targon69]

Gerv wrote:

>The problem here is that, AIUI, Mozilla currently doesn't remember the form 
>contents from previous forms in the history. So, if the new info opened in the 
>same window, you couldn't go "back" to change stuff.

Going back and getting the old form input seems to work with my copy of Mozilla
(0.9.3). Why not use the same window now?

On a related note: I tried to unblock window.open by setting 

user_pref("capability.policy.default.Window.open", "noAccess");
user_pref("capability.policy.trusted.sites", "http://www.mozilla.org");
user_pref("capability.policy.trusted.Window.open", "allAccess");
in my user.jf. But it doesn't work. Should I file another bug report or does
someone spot an error in these settings??

Comment 15

[Gervase Markham [:gerv]]

Did you make sure to shut down Mozilla before editing prefs.js? I.e. are the
prefs still in the file?

Gerv

Comment 16

[Gervase Markham [:gerv]]

OK, the current plan is to rewrite Bugzilla Helper as a .cgi which is part of
Bugzilla. This will eliminate this problem. Look for that in the next few weeks.

Gerv

Comment 17

[targon69]

Opening the new window works now. There is an alert dialog with an "8" in it
first, but then the window pops up. And yes, I restart mozilla after I edit user.js.

Comment 18

[Gervase Markham [:gerv]]

That was debugging code. I suck.

Gerv

Comment 19

[Gervase Markham [:gerv]]

*** Bug 103283 has been marked as a duplicate of this bug. ***

Comment 20

[Gervase Markham [:gerv]]

*** Bug 113440 has been marked as a duplicate of this bug. ***

Comment 21

[Vincent Lefevre]

With Mozilla 2002040108 under PC/Linux, the popup in the bugzilla helper no
longer appears (I've tried twice). My prefs.js contains:

user_pref("capability.policy.allowpopups.Window.open", "sameOrigin");
user_pref("capability.policy.allowpopups.sites", "http://www.mozilla.org
http://bugzilla.mozilla.org http://www.xxxxxxxxx.com");
user_pref("capability.policy.default.Window.open", "noAccess");

but it used to work.

Comment 22

[Gervase Markham [:gerv]]

Bugzilla Helper hasn't changed. If it used to work, then file a bug on Mozilla :-)

Gerv

Comment 23

[mental]

Looks like he did, bug 144857.

Comment 24

[Mike Young]

Ummm, Ok, this works because onSubmit is allowed to call window.open now via the
pref for unrequested windows. (See bug 159036 about this possibly changing...)

Since this works, the text about it not working with popup blocking on should be
removed. once that is done, this is fixed.

Comment 25

[Gervase Markham [:gerv]]

WFM, then.

Gerv

Comment 26

[Mike Young]

Gerv, can you remove the red-text comment that says this won't work if popup
blocking is turned on? Its kind of misleading and people may start thinking
pop-up blocking is broken...

Comment 27

[Gervase Markham [:gerv]]

Done. Wait 1 hour for the update.

Gerv

Comment 28

[Mike Young]

verif

Comment 29

[Hixie (not reading bugmail)]

Webtools/Bugzilla Helper is being retired.

Comment 30

[Dave Miller [:justdave]]

clearing milestone on all DUPLICATE/WONTFIX/WORKSFORME/INVALID so they'll show
up as untriaged if they get reopened.  "Jiminy Cricket!" for the filters (and I
don't care if it's spelled wrong ;)