391777 - Empty Trash Button not functional on yahoo mail

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Marcia Knous [:marcia]]

Seen using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/200708100505 Minefield/3.0a8pre. I am using regular Yahoo mail, *not* Yahoo mail beta.

STR:
1. Try to empty either your bulk mail or your trash by clicking on the "Empty button.
2. Nothing happens.

No errors in console. Specifically irritating on Mac since you can't closet the dialog.

Comment 1

[Brian Polidoro]

0809 1311 works
0809 1507 broke

http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1186690260&maxdate=1186697219

Comment 2

[Boris Zbarsky [:bzbarsky]]

What dialog is this?  What does the source of the dialog look like?

Comment 3

[Brian Polidoro]

Attachment: dialog source

Here's the source of the dialog when I try to empty the bulk folder.

The behavior is different with Minefield than with Firefox.  I would assume it's due to the UA string.  But Minefield is getting a version of Yahoo Mail that presents a dialog that's seems to be spawned by showModalDialog.  Because before showModalDialog was recently implemented the bulk folder would empty without asking any questions.  And the modal dialog did work until the change was made for Bug 389634.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Hmm.  In DOM Inspector does the OK button have the "onclick" property set to the OK_Click function?

Comment 5

[Boris Zbarsky [:bzbarsky]]

And if you can get a url bar in that dialog, does "javascript:window.close()" in that url bar work?

Comment 6

[Brian Polidoro]

The onlcick handler seems to do something.  If I close the dialog with the button in the top right corner then nothing happens.  If I click the empty button and then close the dialog with the close button the bulk folder is emptied.  Unlike comment#0 I can close the window because I'm using Windows. 

Also the DOM inspector does list 'click' for the empty button with a value of: function click() {
    [native code]
}

I don't know of a way to get a URL bar.  The window doesn't seem to be affected by dom.disable_window_open_feature.location.   

Comment 7

[Brian Polidoro]

Attachment: testcase

From looking at their code this is essentially how they are opening the dialog.  And luckily I can use the first attachment as the source for the dialog.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> function click() {
>     [native code]
> }

That would be the bug.  Sounds like we're not attaching arguments correctly...  Thank you for the testcase!  Looking into it.

> The window doesn't seem to be affected
> by dom.disable_window_open_feature.location.   

Er.. we should fix that.  Want to file a bug?

Comment 9

[Boris Zbarsky [:bzbarsky]]

> That would be the bug. 

Or not.  That's the right thing for the "click" property.  And the "onclick" property (not the same thing) is also correct.

The real issue here is that nsGlobalWindow::Close is a no-op if IsInModalState() is true.  And the patch in bug 389634 changed things so that we are now (correctly, fwiw) in modal state while the modal dialog is up.

Possibly related: if I close the window with the window manager, I get:

###!!! ASSERTION: Uh, LeaveModalState() called w/o a reachable top window?: 'Error', file ../../../../mozilla/dom/src/base/nsGlobalWindow.cpp, line 5032

with this stack:
#0  0xb50551c9 in nsGlobalWindow::LeaveModalState (this=0xaf9fe910)
    at ../../../../mozilla/dom/src/base/nsGlobalWindow.cpp:5032
#1  0xb5528a2d in ~nsAutoWindowStateHelper (this=0xbfffc4e4)
    at ../../../../../mozilla/embedding/components/windowwatcher/src/nsPrompt.cpp:195
#2  0xb5533884 in nsWindowWatcher::OpenWindowJSInternal (this=0x82055e8, 
    aParent=0x87b2238, aUrl=0xaf605fd8 "foo.html", aName=0x0, 
    aFeatures=0xaf604b48 "modal=1,status=1,height=500px,width=500px,resizable=1,scrollbars=0,scrollbars=1,centerscreen=1,resizable=0", aDialog=1, argv=0xaf9f8408, 
    aCalledFromJS=0, _retval=0xbfffcc44)
    at ../../../../../mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp:943

The problem is that mDocShell in that modal window is null by the time ~nsAutoWindowStateHelper happens.  I don't get that with alert(), say...

Comment 10

[Johnny Stenback (:jst)]

FWIW, one can always load a URL in a modal content dialog by hitting Alt+D to get an open location dialog, whether the URL bar is hidden or not. That's not to say that not respecting the pref for the location bar is correct or anything...

Comment 11

[Hank Mills]

(In reply to comment #0) 
>Specifically irritating on Mac since you can't closet the dialog.

as a work around, cmd+w closes the dialog.
(and as a side cmd+m will minimize it. oh the fun)

Comment 13

[Bret Reckard]

In Reference to Bug 393343 and 391777.  After quitting the browser and restoring the session, the modal dialogue is stripped off the Yahoo Mail page and is presented in a new browser window See Attached image "New Close Window".  This seems odd.

FFx Version:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007081704 Minefield/3.0a8pre

Comment 14

[Bret Reckard]

Attachment: New Close Window

Comment 15

[Boris Zbarsky [:bzbarsky]]

That's a separate bug (in session restore).  Please file it.

Comment 16

[Bret Reckard]

Done, See the following for more info:

Bug 393466 – Modal dialogue stripped and presented in new Window after session restore

Comment 17

[Brian Polidoro]

> > The window doesn't seem to be affected
> > by dom.disable_window_open_feature.location.   
> 
> Er.. we should fix that.  Want to file a bug?
> 
I see now there's Bug 393900.

Comment 18

[Brian Polidoro]

The font size in the dialog seems to be set from the font size in the tab that is opening the dialog.  I have the font size increased in the tab which results in the contents not fitting in the empty trash dialog.  I used to be able to scroll the rest of the contents into view.  But recently that changed.  From the timing I think that's a result of bug 393900.  So then I can't access the empty button without resetting the size of the font.  Is that a bug?  

Comment 19

[Brian Polidoro]

(In reply to comment #18)
Whoops, that's my bad.  I had dom.disable_window_open_feature.resizable true when it should have been false.  

Comment 20

[Johnny Stenback (:jst)]

Attachment: Fix.

This was due to a stupid mistake when the showModalDialog() code went in. We ended up telling the modal dialog itself that there's a modal dialog open against it, not that there's a modal dialog open against its parent (opening window). Duh.

Comment 21

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 282345 [details] [diff] [review]
Fix.

please add a mochitest for this too

Comment 22

[Damon Sicore (:damons)]

Targeting M9 as this bug will block beta.

Comment 23

[Johnny Stenback (:jst)]

Attachment: Fix, with test 'n all.

Comment 24

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 282479 [details] [diff] [review]
Fix, with test 'n all.

You don't need the addLoadEvent and SimpleTest.waitForExplicitFinish/finish stuff, just put the test code inline. Also, |ok| only takes two arguments.

Comment 25

[Boris Zbarsky [:bzbarsky]]

> Also, |ok| only takes two arguments.

No, it takes 3.  First arg is the predicate, second arg is the test name, third arg is the message to output when the test fails.  See 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/testing/mochitest/tests/SimpleTest/SimpleTest.js&rev=1.9&mark=36#34

Now sadly a lot of people skip that third arg when calling ok()...

Comment 26

[Johnny Stenback (:jst)]

Fix checked in, with updated testcase.

Comment 27

[Ray Kiddy]

Is it just me? This bug is giving me a failure when I run it locally. I built a
copy of FF, checked out 20071202_202630_PST, with mozconfig:
mk_add_options MOZ_CO_PROJECT=browser
ac_add_options --enable-debug
ac_add_options --enable-application=browser
ac_add_options --enable-test
ac_add_options --enable-gtktest
ac_add_options --enable-mochitest
ac_add_options --enable-libIDLtest
ac_add_options --enable-glibtest

I am on Mac OS X 10.4.10 with a fairly standard tool set.

I launched with "perl ./runtests.pl --autorun".

I see this in the web page when I click on the test:

not ok - Unexpected result from showModalDialog got null, expected "foo"

and this in the stdout:

++DOMWINDOW == 61
###!!! ASSERTION: cannot call on a dirty frame not currently being reflowed: '!NS_SUBTREE_DIRTY(this) || (GetStateBits() & NS_FRAME_IN_REFLOW)', file nsFrame.cpp, line 556
###!!! ASSERTION: cannot call on a dirty frame not currently being reflowed: '!NS_SUBTREE_DIRTY(this) || (GetStateBits() & NS_FRAME_IN_REFLOW)', file nsFrame.cpp, line 556
###!!! ASSERTION: cannot call on a dirty frame not currently being reflowed: '!NS_SUBTREE_DIRTY(this) || (GetStateBits() & NS_FRAME_IN_REFLOW)', file nsFrame.cpp, line 556
++WEBSHELL 0x31cf29d0 == 12
++DOMWINDOW == 62
++DOMWINDOW == 63
WARNING: Calling SetWindowTitlebarColor on window that isn't of the ToolbarWindow class.: 'SameCOMIdentity(GetHiddenWindowWidget(), (nsIWidget*)this)', file nsCocoaWindow.mm, line 1115
++WEBSHELL 0x159db570 == 13
++DOMWINDOW == 64
###!!! ASSERTION: Class name and proto chain interface name mismatch!: 'nsCRT::strcmp(CutPrefix(name), mData->mName) == 0', file nsDOMClassInfo.cpp, line 3650
WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 940
++DOMWINDOW == 65
###!!! ASSERTION: Class name and proto chain interface name mismatch!: 'nsCRT::strcmp(CutPrefix(name), mData->mName) == 0', file nsDOMClassInfo.cpp, line 3650
WARNING: empty langgroup: file gfxFont.cpp, line 875
WARNING: empty langgroup: file gfxFont.cpp, line 875
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file nsJSEnvironment.cpp, line 2425
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file nsGlobalWindow.cpp, line 2255
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file nsWindowWatcher.cpp, line 736
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file nsGlobalWindow.cpp, line 6869
WARNING: empty langgroup: file gfxFont.cpp, line 875
###!!! ASSERTION: cannot call on a dirty frame not currently being reflowed: '!NS_SUBTREE_DIRTY(this) || (GetStateBits() & NS_FRAME_IN_REFLOW)', file nsFrame.cpp, line 556

Only one other test is failing. In case it is related, it is:
/tests/browser/base/content/test/test_bug395533.html