41755 - Cannot use the window feature "modal" when opening dialogs on Solaris

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect, P3)

Description

[Edwin Hoogerbeets]

If you attempt to open a window or a dialog in some javascript located in 
your chrome, and that call is given the windowfeature "modal", mozilla will 
hang on Solaris. The exact same chrome works fine on Windows.

Example:

window.openDialog("chrome://myproject/content/editServer.xul", "editServer", 
"modal,chrome");

If you take out the "modal", the window opens just fine, but of course, the 
openDialog() call returns right away and no return code is given. This is
a problem because you therefore can't use dialogs to get an answer from 
the user in response to a question you have.

This same chrome used to work in M13.

Comment 1

[Brendan Eich [:brendan]]

Hmm, why would this regress on Solaris?

/be

Comment 2

[Edwin Hoogerbeets]

I should add this bug occurs in the Solaris version of the M15 milestone code 
that I got directly from mozilla.org as a source tar ball and compiled myself. 
Don't know it might have regressed!

Comment 3

[Edwin Hoogerbeets]

I just downloaded the precompiled M15 build for solaris from mozilla.org and 
tried our chrome with that, and it has the exact same behaviour as the build I 
made myself. So, I'm pretty sure it was built correctly here.

Comment 4

[Peter Trudelle]

nominating for nsbeta2, cc pavlov.  can anyone confirm this?

Comment 5

[Dan M]

pavlov, it's rumoured, has a sparc box with his name on it, if not his 
fingerprints.

Comment 6

[leger]

Putting on [nsbeta2-] radar. Not critical to Netscape 6 beta2.  

Comment 7

[Asa Dotzler [:asa]]

changing status to New just to make sure this doesn't get lost.

Comment 8

[Edwin Hoogerbeets]

More information: modal dialogs work in normal operation! For example, the
AccountWizard dialog in the messenger app seems to work fine. Upon further 
investigation, I found out that modal dialogs are only a problem from the 
onLoad handlers of other windows when mozilla is first starting up.

The modal dialog I am using is called from an onLoad handler for my 
starting window. My first window's xul file, project.xul, starts like this:

<window id="project-window"
        xmlns:html="http://www.w3.org/TR/REC-html40"
        xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
        title="&window.title;" align="horizontal"  onload="Init();"
        x="5" y="5"
        windowtype="fusion:project">

    <html:script language="JavaScript" 
src="chrome://fusion-project/content/project.js" encoding="UTF-8"/>

In my project.js file, in the Init() function I have:

window.openDialog("chrome://fusion-global/content/selectServer.xul","SelectThis"
,"modal,chrome");

The dialog selectServer.xul is the one that doesn't appear. My guess is that 
is because of re-entrancy problems, or because things aren't initialized yet, or 
something like that.

When you change the project.xul to add a new button, and call the Init() 
function as the result of clicking on this button rather than calling it from 
the onLoad handler, then the selectServer.xul dialog appears properly.

Please assign this bug to the Solaris porting group at Sun.

Comment 9

[Stuart Parmenter]

i will take a look at this if you can attach all the files I need to test this 
to the bug.

Comment 10

[Peter Trudelle]

Pav, since this bug is nsbeta2-, you're not at liberty to work on it other than 
as a module owner reviewing a fix contributed by an external developer.  If you 
disagree, you need to renominate with a compelling argument why we should hold 
nsbteta2 for it.

Comment 11

[Peter Trudelle]

How do we assign this bug to the Solaris porting group at Sun?  Is there any
reason we would hold Netscape6 release for this bug?  If not, please future.

Comment 12

[Rich Burridge]

If you feel that you must "get it off your plate" and assign 
this bug to somebody in the "Solaris Porting group", then assign
it to me. I'd prefer that this didn't happen though because:

* we are a small group (4 about to become 3 on Friday), and we
  have a lot of other things that need to be addressed. We aren't
  going to be looking at it any time soon, so it'll just sit there.
* we currently have limited in-depth knowledge of the Mozilla
  code. Pav (assuming he wasn't busy on other things), could
  probably reproduce and fix this problem in a fraction of the
  time we could.

If the fact that this is marked as a blocker is holding up
shipment of Mozilla beta2, then I suggest it should be
reprioritized. I suspect you will find that this isn't
just Solaris specific, and can probably be recreated on
Linux as well. Edwin, can you possibly do that?

Edwin, I suggest that also (if possible) you do what Pav
requested and try to attached a set of files that reproduce 
this problem. Then perhaps it can be investigated in more 
detail after beta2 is out. Thanks.

Comment 13

[Edwin Hoogerbeets]

Well, since reporting this bug on M15, we have moved our development to M16. So, 
I attempted to create a small set of files that show this bug with M16 chrome... 
and guess what? It worked. No modal dialog problems. So I went back to our full 
chrome, and it also works there too. I guess this problem just went away by 
itself in M16.

So, I'm not sure what to do with this bug. Assign it a very low priority or 
something? I'm not sure if it was actively fixed or if it just happens to work 
now. If it just happens to work, then it's still a bug that might creep up and 
bite us on the toe later on.

Comment 14

[Rich Burridge]

Edwin, thanks for trying this out with M16. I've reset the 
severity to normal. I suggest we keep it open until Mozilla
beta 2 comes out, and you can confirm that it works there too.
If it does, then it can be closed out. Pav, you might like
to remove the nsbeta2- status whiteboard and keywords if that's
appropriate.

Comment 15

[Stuart Parmenter]

i'm marking this works for me.  my build works fine.  solaris2.7 build from
wednesday (7-26-2000)