Here there are two issues: It looks like modal/modeless messages are showed inside a browser widnow (analogue of window.open() script method). I guess we should use window.openDialog() script method. Message dialogs are not resizable ().

I guess dialogs should be centerscreened

(In reply to comment #1) > I guess dialogs should be centerscreened > They used to be centered. I guess that something regressed.

(In reply to comment #0) > Here there are two issues: > > It looks like modal/modeless messages are showed inside a browser widnow > (analogue of window.open() script method). I guess we should use > window.openDialog() script method. > > Message dialogs are not resizable (). > Why should they be resizeable? I've always thought of xf:message being just like a JS alert and they aren't resizeable.

(In reply to comment #3) > Why should they be resizeable? I've always thought of xf:message being just > like a JS alert and they aren't resizeable. > For sure I'm not sure :) but if we can put whole web page (if i'm not wrong) then resizeable looks reasonable. From other hand I agree with you if you shows couple lines then out message should looks like alert/e.t.c. Btw does xforms specs has something to specify caption of message dialog?

(In reply to comment #4) > (In reply to comment #3) > Btw does xforms specs has something to specify caption of message dialog? > Not that I know of.

This bug depends on bug 348689 since it partially fixes issues of this bug like asking to use xul:dialog.

>Btw does xforms specs has something to specify caption of message dialog? There's no reason that xf:message/@level=modal has to be shown as a pop-up at all. The Dojo inline popups are quite nice and would be valuable as well, especially if the Mozilla implementation decides to allow all xforms UI controls inside xf:message, not just xf:output; the spec allows for this by saying the host language gets to pick.

(In reply to comment #7) > >Btw does xforms specs has something to specify caption of message dialog? > There's no reason that xf:message/@level=modal has to be shown as a pop-up at > all. > The Dojo inline popups are quite nice and would be valuable as well, especially > if the Mozilla implementation decides to allow all xforms UI controls inside > xf:message, not just xf:output; the spec allows for this by saying the host > language gets to pick. > I'd think that modal would have to be a popup. Since it is 'modal', most users understand that a message box might have to be dismissed before accessing the rest of the form. They might not understand that if the modal message were presented as something other than a message box. For level="modeless", sure, the more flexibility the better.

(In reply to comment #8) Here's an example of a dojo modal dialog box inline: http://www.lukew.com/ff/entry.asp?224 It's good for choosers, or additional-info dialogs that pop up. Anyway, my point is that the XForms Rec allows this kind of flexibility.

I'm not sure xforms should contrive something special for message appearance since mozilla has already modal and modaless windows. But it's fine if we allow to redefine appearance for our messages and someone will be capable to turn on dojo window instead ours. > if the Mozilla implementation decides to allow all xforms UI controls inside > xf:message, not just xf:output; the spec allows for this by saying the host > language gets to pick. I agree message content shouldn't be bound by such restriction. But implementation can be trickly.

1) Messages are dialogs. 2) Centerscreened 3) Modeless messages have minimize button 4) Messages have sizes like standard alert.

(In reply to comment #10) > > if the Mozilla implementation decides to allow all xforms UI controls inside > > xf:message, not just xf:output; the spec allows for this by saying the host > > language gets to pick. > > I agree message content shouldn't be bound by such restriction. But > implementation can be trickly. This feature is provided by PicoForms and X-Smiles, among others. The use of pop-up dialog boxes is a very strong use case. I understand it may not be an 0.7 feature but as it is allowed in the XForms 1.0 Rec, I believe you should consider it for the 1.0 XPI.

(In reply to comment #12) > (In reply to comment #10) > > > if the Mozilla implementation decides to allow all xforms UI controls inside > > > xf:message, not just xf:output; the spec allows for this by saying the host > > > language gets to pick. > > > > I agree message content shouldn't be bound by such restriction. But > > implementation can be trickly. > > This feature is provided by PicoForms and X-Smiles, among others. I posted bug 351048 for that. > The use of pop-up dialog boxes is a very strong use case. > I understand it may not be an 0.7 feature but as it is allowed in the XForms > 1.0 Rec, I believe you should consider it for the 1.0 XPI. > Popup dialog boxes is not bad idea. But they should be styled and default styling should be compatible with how standard messages look. Therefore I doubt we should use popup boxes by default. But I agree we shoudn't chain xforms authors and they probably should have possibility to use own popup styled dialogs for xforms messages.

(In reply to comment #12) > (In reply to comment #10) > > > if the Mozilla implementation decides to allow all xforms UI controls inside > > > xf:message, not just xf:output; the spec allows for this by saying the host > > > language gets to pick. > > > > I agree message content shouldn't be bound by such restriction. But > > implementation can be trickly. > > This feature is provided by PicoForms and X-Smiles, among others. Btw, you can use @src attribute on message to avoid this. Just workaround ;)

Comment on attachment 236416 [details] [diff] [review] patch >Index: extensions/xforms/nsXFormsMessageElement.cpp >=================================================================== >RCS file: /cvsroot/mozilla/extensions/xforms/nsXFormsMessageElement.cpp,v >retrieving revision 1.24 >diff -u -8 -p -r1.24 nsXFormsMessageElement.cpp >--- extensions/xforms/nsXFormsMessageElement.cpp 30 Aug 2006 15:41:29 -0000 1.24 >+++ extensions/xforms/nsXFormsMessageElement.cpp 1 Sep 2006 17:08:06 -0000 >@@ -753,18 +751,21 @@ nsXFormsMessageElement::HandleModalAndMo > nsCAutoString b64String; > b64String.AppendLiteral("data:application/vnd.mozilla.xul+xml;base64,"); > b64String.Append(b64); > PR_Free(b64); > > CopyUTF8toUTF16(b64String, messageURL); > } > >- if (aLevel.EqualsLiteral("modal")) >+ if (aLevel.EqualsLiteral("modal")) { > options.AppendLiteral(",modal"); >+ } else if (aLevel.EqualsLiteral("modaless")) { >+ options.AppendLiteral(",minimizable"); >+ } should be 'modeless' not 'modaless' >Index: extensions/xforms/resources/content/xforms-message.xul >=================================================================== >RCS file: /cvsroot/mozilla/extensions/xforms/resources/content/xforms-message.xul,v >retrieving revision 1.1 >diff -u -8 -p -r1.1 xforms-message.xul >--- extensions/xforms/resources/content/xforms-message.xul 30 Aug 2006 15:41:29 -0000 1.1 >+++ extensions/xforms/resources/content/xforms-message.xul 1 Sep 2006 17:08:06 -0000 >@@ -36,26 +36,30 @@ > - > - ***** END LICENSE BLOCK ***** --> > > <?xml-stylesheet href="chrome://global/skin/" type="text/css"?> > > <dialog id="XFormsMessageDialog" > xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" > title="[XForms]" >- width="200px" >- height="200px" >+ width="325px" >+ height="120px" > buttons="accept" > onload="loadMessageURL()"> > > <script> >+ <![CDATA[ > function loadMessageURL() > { > var url = window.arguments[0]; >- if (url) >- document.getElementById("browser").loadURI(url); >+ if (url) { >+ var browser = document.getElementById("browser"); >+ browser.loadURI(url); >+ } > } >+ ]]> > </script> why this change? Might want to comment it so no one changes it back. With those, r=me

>- width="200px" >- height="200px" >+ width="325px" >+ height="120px" To be more consistent with dialog that is show by alert() javascript function. Other changes don't make a sense, therefore I removed them.

Though, this does make the modal messages a bit ugly in the testcases of https://bugzilla.mozilla.org/show_bug.cgi?id=333029 But that sizing problem is not caused by this patch.

checked into 1.8.0 branch on 2006/09/21

checked into 1.8 branch on 2006/11/21