Empty Trash Button not functional on yahoo mail

VERIFIED FIXED in mozilla1.9beta1

Status

()

VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: marcia, Assigned: jst)

Tracking

({regression})

Trunk
mozilla1.9beta1
regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-testsuite +
in-litmus ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

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.
What dialog is this?  What does the source of the dialog look like?
Flags: blocking1.9?

Comment 3

11 years ago
Created attachment 277080 [details]
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.
Hmm.  In DOM Inspector does the OK button have the "onclick" property set to the OK_Click function?
And if you can get a url bar in that dialog, does "javascript:window.close()" in that url bar work?

Comment 6

11 years ago
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

11 years ago
Created attachment 277098 [details]
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.
> 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?


Flags: in-testsuite?
> 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...
Component: General → DOM
QA Contact: general → general
(Assignee)

Comment 10

11 years ago
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

11 years ago
(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)
Duplicate of this bug: 393343

Comment 13

11 years ago
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

11 years ago
Created attachment 277959 [details]
New Close Window
That's a separate bug (in session restore).  Please file it.

Comment 16

11 years ago
Done, See the following for more info:

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

Comment 17

11 years ago
> > 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.

Assignee: nobody → jst
Flags: blocking1.9? → blocking1.9+
(Reporter)

Updated

11 years ago
Flags: in-litmus?

Comment 18

11 years ago
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

11 years ago
(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.  
(Assignee)

Comment 20

11 years ago
Created attachment 282345 [details] [diff] [review]
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.
Attachment #282345 - Flags: superreview?(jonas)
Attachment #282345 - Flags: review?(jonas)
Attachment #282345 - Flags: approval1.9?
Comment on attachment 282345 [details] [diff] [review]
Fix.

please add a mochitest for this too
Attachment #282345 - Flags: superreview?(jonas)
Attachment #282345 - Flags: superreview+
Attachment #282345 - Flags: review?(jonas)
Attachment #282345 - Flags: review+
Attachment #282345 - Flags: approval1.9?
Attachment #282345 - Flags: approval1.9+
Targeting M9 as this bug will block beta.
Target Milestone: --- → mozilla1.9 M9
(Assignee)

Comment 23

11 years ago
Created attachment 282479 [details] [diff] [review]
Fix, with test 'n all.
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.
Attachment #282479 - Flags: superreview+
Attachment #282479 - Flags: review+
> 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()...
(Assignee)

Comment 26

11 years ago
Fix checked in, with updated testcase.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Status: RESOLVED → VERIFIED

Updated

11 years ago
Flags: in-testsuite? → in-testsuite+
Version: unspecified → Trunk

Comment 27

11 years ago
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
You need to log in before you can comment on or make changes to this bug.