xforms message should be resizeable and showed inside dialog

RESOLVED FIXED

Status

Core Graveyard
XForms
RESOLVED FIXED
12 years ago
a year ago

People

(Reporter: surkov, Assigned: surkov)

Tracking

({fixed1.8.0.8, fixed1.8.1.1})

Trunk
fixed1.8.0.8, fixed1.8.1.1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

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

Comment 1

12 years ago
I guess dialogs should be centerscreened

Comment 2

12 years ago
(In reply to comment #1)
> I guess dialogs should be centerscreened
> 

They used to be centered.  I guess that something regressed.

Comment 3

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

Comment 4

12 years ago
(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?

Comment 5

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

Comment 6

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

Comment 7

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


Comment 8

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

Comment 9

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

Comment 10

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

Comment 11

11 years ago
Created attachment 236416 [details] [diff] [review]
patch

1) Messages are dialogs.
2) Centerscreened
3) Modeless messages have minimize button
4) Messages have sizes like standard alert.
Assignee: xforms → surkov.alexander
Status: NEW → ASSIGNED
Attachment #236416 - Flags: review?(aaronr)

Comment 12

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


(Assignee)

Comment 13

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

Comment 14

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

11 years ago
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
Attachment #236416 - Flags: review?(aaronr) → review+
(Assignee)

Comment 16

11 years ago
Created attachment 237955 [details] [diff] [review]
patch2

>-        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.
Attachment #236416 - Attachment is obsolete: true
Attachment #237955 - Flags: review?(Olli.Pettay)
Attachment #237955 - Flags: review?(Olli.Pettay) → review+
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.

Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch

Comment 18

11 years ago
checked into 1.8.0 branch on 2006/09/21
Keywords: fixed1.8.0.8

Comment 19

11 years ago
checked into 1.8 branch on 2006/11/21
Keywords: fixed1.8.1.1
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.