546533 - Clicking "OK" on alert from SVG-edit's save command --> assertion spam, extra tabs, extra alerts [ASSERTION: Unexpected document: 'capturingContent->GetCurrentDoc() == GetDocument()', file nsPresShell.cpp, line 6162]

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[worms]

Privacy setting in Firefox: 

Use custom setting for history: selected
Unchecked: Remember browsing history
Unchecked: Remember download history
Unchecked: Remember search..

Checked: Accept cookies from sites
Unchecked: Accept third-party cookies
Keep until: ask me every time

1. Go at the above URL and draw something
2. Go in the Main Menu, choose "Save"

Normally, if it's the first time you save something in a session, a popup message would show, telling the user how to Save a SVG, with a warning if there are gradients in the drawing, and a tab with the data:URI with the drawing is created.

As of build 
ftp://ftp.mozilla.org/pub/firefox/nightly/2009/09/2009-09-18-04-mozilla-central

clicking on "allow for session" in the popup "Confirm setting cookie" creates a new data:URI tab from SVG-edit, with the drawing.

about:buildconfig says: Built from http://hg.mozilla.org/mozilla-central/rev/41dd493c42c9

This doesn't happen in 
ftp://ftp.mozilla.org/pub/firefox/nightly/2009/09/2009-09-17-04-mozilla-central

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090917 Minefield/3.7a1pre

about:buildconfig
Built from http://hg.mozilla.org/mozilla-central/rev/3079370d6597

where one can click "allow for session" for the cookie and where the warning message from SVG-edit is received normally: only one tab is created.

I'm not able to narrow the build further down, as there is no WIN32 zip on:
ftp://ftp.mozilla.org/pub/firefox/nightly/2009/09/2009-09-18-03-mozilla-central/

Also note that in more recent builds (for example, in the 3.7 Alpha Developer preview), clicking the cookie message will create one new tab indefinitely (you also cannot see the cookie details)

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to comment #0)
> As of build 
> ftp://ftp.mozilla.org/pub/firefox/nightly/2009/09/2009-09-18-04-mozilla-central
[...]
> I'm not able to narrow the build further down, as there is no WIN32 zip on:
> ftp://ftp.mozilla.org/pub/firefox/nightly/2009/09/2009-09-18-03-mozilla-central/

Those are two different build directories for the same day -- it's expected that WIN32 builds would only be in one or the other.

Pushlog for regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3079370d6597&tochange=41dd493c42c9

From that range, this checkin message sounds particularly related:
"Bug 516603 - make existing addTab and loadOneTab callers pass a hashed arguments object."

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to comment #1)
> From that range, this checkin message sounds particularly related:
> "Bug 516603 - make existing addTab and loadOneTab callers pass a hashed
> arguments object."

... however, that bug's patch also landed in 1.9.2 (long ago), and I think wormxulla said in IRC that this bug here doesn't affect 1.9.2. (right?)

Nothing else from the pushlog range looks particularly suspicious, though...

Comment 3

[Daniel Holbert [:dholbert]]

ALTERNATE STR:
 1. Start up Firefox with fresh profile.
 2. In "Privacy" prefs section, pick "use custom settings", and uncheck "Accept cookies from sites"
 3. Go to URL
 4. Click pencil icon in upper-left corner, and choose "Save Image"
 5. Click "OK" on the alert that pops up. (message is "Select "Save As..." in your browser to save this image as an SVG file")

EXPECTED RESULTS: Alert should go away.
ACTUAL RESULTS: When I click "OK", the alert doesn't go away -- instead, a new one appears (with a new tab).  This repeats each time I click "OK" on the topmost alert.

NOTE: If I use the [spacebar] or [enter] key on my keyboard to activate the "OK" button on the topmost alert, instead of clicking it, then everything works fine -- the alert goes away, and no new tabs appear.  (After that point, if I've got a stack of alerts open, I can use either keyboard or mouse-click to (re)-activate "OK" on all the other remaining alerts, and they'll allow themselves to be dismissed.)

I've confirmed this behavior in today's nightly:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a2pre) Gecko/20100216 Minefield/3.7a2pre
and I've confirmed that 3.6 nightly is unaffected:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.2pre) Gecko/20100216 Namoroka/3.6.2pre

Comment 4

[Daniel Holbert [:dholbert]]

(The "accept cookies from sites" setting is only required because svg-edit uses a cookie to remember whether it's shown you the dialog before.  If I don't touch that preference -- i.e. if I skip step 2 in comment 3's STR -- then I still get 2 alerts and 2 new tabs, instead of infinite copies of both.  That's still 1 extra alert & 1 extra tab.)

Comment 5

[worms]

Indeed, this doesn't affect 1.9.2:

3.6.2pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2pre) Gecko/20100216
Namoroka/3.6.2pre

works normally, as expected with SVG-edit (same privacy/cookies settings): 
"allow for session" can be clicked, the warning message pops-up, and only one
tab with the data:URI opens.

(mid-air collision!)

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to comment #2)
> (In reply to comment #1)
> > From that range, this checkin message sounds particularly related:
> > "Bug 516603 - make existing addTab and loadOneTab callers pass a hashed
> > arguments object."
> 
> ... however, that bug's patch also landed in 1.9.2 (long ago), and I think
> wormxulla said in IRC that this bug here doesn't affect 1.9.2.

... BUT: apparently a chunk of that bug's m-c patch didn't make it to 1.9.2, apparently on accident.  The chunk is in openURI(), under "case Ci.nsIBrowserDOMWindow.OPEN_NEWTAB", which sounds pretty related to this bug.  I've noted this apparent oversight in Bug 516603 comment 9.

It seems pretty likely that this particular chunk is what caused this regression on mozilla-central.  Marking dependency.

Comment 7

[Daniel Holbert [:dholbert]]

Or... given that this is click-dependent (as noted in comment 3), this changeset also looks suspicious: "Bug 516880, use the right presshell when getting frames during mouse capture"

*That* checkin hasn't landed on 1.9.2, so if that's the cause, it'd definitely make sense that this is trunk-only.

Comment 8

[Daniel Holbert [:dholbert]]

Yeah, pretty sure this is from Bug 516880.  When I run comment 3's STR in a debug build, I get tons of these assertions, for each mouse-micro-move across the topmost alert dialog:
###!!! ASSERTION: Unexpected document: 'capturingContent->GetCurrentDoc() == GetDocument()', file ../../../mozilla/layout/base/nsPresShell.cpp, line 6162

I'm guessing that the alert is generated from one tab, but appears on top of another, and that confuses us. Or something like that.

Comment 9

[Neil Deakin]

This should be fixed by bug 536481.

Comment 10

[worms]

Just because I'm not sure what the status of bug 536481 is (the fix is submitted but waiting for review?):

then bug 536481 will go in the 1.9.2 branch and in the trunk?

Comment 11

[Neil Deakin]

If this bug applies to 1.9.2 as well then that's an entirely different cause and would require a different fix.

Comment 12

[worms]

Yes, sorry. I got confused with another issue. 
Bug 536481 will only go in the trunk, and I still have to find the cause of another issue.

Thanks for the answer and sorry for the bugspam.

Comment 13

[worms]

I can confirm that the assertion spam and extra tab doesn't happen anymore with

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100221 Minefield/3.7a2pre

http://hg.mozilla.org/mozilla-central/rev/ab5aec9ca05b

after bug 536481 has been fixed.

Thank you!