Closed Bug 41755 Opened 25 years ago Closed 25 years ago

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

Categories

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

Sun
Solaris
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: edwin, Assigned: pavlov)

Details

(Keywords: helpwanted, Whiteboard: [nsbeta2-])

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.
Hmm, why would this regress on Solaris? /be
Assignee: waterson → danm
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!
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.
nominating for nsbeta2, cc pavlov. can anyone confirm this?
Keywords: nsbeta2
Keywords: helpwanted
Whiteboard: clueless. anyone with a sparc box care to take this on?
pavlov, it's rumoured, has a sparc box with his name on it, if not his fingerprints.
Assignee: danm → pavlov
Whiteboard: clueless. anyone with a sparc box care to take this on?
Putting on [nsbeta2-] radar. Not critical to Netscape 6 beta2.
Whiteboard: [nsbeta2-]
changing status to New just to make sure this doesn't get lost.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
i will take a look at this if you can attach all the files I need to test this to the bug.
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.
Target Milestone: --- → M20
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.
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.
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.
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.
Severity: blocker → normal
i'm marking this works for me. my build works fine. solaris2.7 build from wednesday (7-26-2000)
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Component: XP Miscellany → Widget: Gtk
You need to log in before you can comment on or make changes to this bug.