MozillaZine

[XUL] Preference/Options dialog behaviour (OS X, FF3.0)

Talk about add-ons and extension development.
TripleSix
 
Posts: 17
Joined: August 18th, 2007, 3:40 pm

Post Posted June 25th, 2008, 12:27 am

I have some people testing out my plugin, and one of them is using Firefox 3.0 under OS X. He reported this problem with the Preferences / Options dialog of the plugin.

Problem 1: This dialog has six prefpanes, each iconed and clickable in the button bar at the top. This dialog is auto-sized, or at least should be, and it all works as intented on FF3.0/WinXP. But in OS X something weird happens. The dialog's width is alright, but in the height it cuts off the bottom part - exactly the amount the top button bar takes up. When this button bar is hidden, it's a perfect fit... But of course removal is not an option ;)

Problem 2: in FF/WinXP this dialog shows the OK and CANCEL button at the bottom. These buttons do additional things more than just accepting the preference changes. But again, in OS X, these buttons somehow don't show up. I believe there were similar reports of this problem on linux systems. I've added the buttons="accept,cancel" attribute to the prefwindow element, but that didn't change a thing.

Basically, this is my current setup of the dialog:

Code: Select all
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css" ?>
<?xml-stylesheet href="chrome://ext/skin/styles.css" type="text/css" ?>

<prefwindow id="prefs" title="options" buttons="accept,cancel" ondialogaccept="return onAccept();" xmlns:html = "http://www.w3.org/1999/xhtml" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

<script type="application/x-javascript">
<![CDATA[
// do stuff
]]>
</script>

      <prefpane id="pane1" image="chrome://ext/skin/img1.png" label="pane1">
         <preferences>
         </preferences>

         <hbox flex="1">
         </hbox>
      </prefpane>

      <prefpane id="pane2" image="chrome://ext/skin/img2.png" label="pane2">
         <preferences>
         </preferences>

         <groupbox id="gb1" orient="vertical" flex="1">
         </groupbox>
      </prefpane>

      <prefpane id="pane3" image="chrome://ext/skin/img3.png" label="pane3">
         <preferences>
         </preferences>

         <hbox>
         </hbox>
      </prefpane>

      <prefpane id="pane4" image="chrome://ext/skin/img4.png" label="pane4">
         <preferences>
         </preferences>

         <groupbox flex="1">
         </groupbox>
      </prefpane>

      <prefpane id="pane5" image="chrome://ext/skin/img5.png" label="pane5">
         <preferences>
         </preferences>

         <groupbox flex="1">
         </groupbox>
      </prefpane>

      <prefpane id="pane6" image="chrome://ext/skin/img6.png" label="pane6">
         <preferences>
         </preferences>

         <hbox>
         </hbox>
      </prefpane>

   </prefwindow>


Problem is that the buttons="accept,cancel" doesn't do a thing, and the ondialogaccept doesn't fire if you close the preferences dialog by other means than the OK button, at least this was the case in FF2.x. I can't test this myself, I don't own a Mac and I don't have a linux machine at hand.

How can I fix this height problem, and how do I force the OK and CANCEL button at the bottom on OS X/Linux machines??

ake79
 
Posts: 1336
Joined: February 17th, 2007, 6:05 am

Post Posted June 25th, 2008, 12:56 am

<script> should be after prefpanes. Known problem, said somewhere in the docs.

Win vs. Linux/Mac: read up on preference browser.preferences.instantApply. You can toggle it to "simulate" Linux/Mac. You shouldn't force OK & Cancel on them, it breaks native look and feel.

(If my memory serves, dialogaccept doesn't fire when dialog is "accepted" if instantApply is enabled for some weird reason. Don't take my word on this, test it. EDIT: Checked. It's "Close" button and its dlgtype is "cancel" so no accept. Maybe onclose?)

Style nit. Use external js and css (prefpane image). Just my opinion.

Don't know if those help, but something...
My extensions: Save File to | ThumbsDown

TripleSix
 
Posts: 17
Joined: August 18th, 2007, 3:40 pm

Post Posted June 25th, 2008, 2:15 am

Thanks ake79.

You're right about the style, it was kind of a mess :). I've split up the XUL and JS, and included the script after all the prefpanes.

I've also played around with the instantApply preference, and it indeed doesn't fire the ondialogaccept event on window closure when it's set to true.
It seems adding a document.documentElement.getButton("accept").hidden = false; line to the onload function serves my need for an OK button, which does fire the ondialogaccept event even if instantApply is set. (Too bad for the native feel...at least until I find a neater solution) - EDIT: onclose could also be a solution, but that goes against the default (and therefore imho expected) cancel behaviour -

Hopefully the relocation of the script helps somehow with the remaining height problem. :)

ake79
 
Posts: 1336
Joined: February 17th, 2007, 6:05 am

Post Posted June 25th, 2008, 2:40 am

Hmm... Just in case.

You did notice that instantApply isn't just a look&feel preference. The changes to preferences are instantly applied hence the name (keep about:config open while using options dialog). So if you close the window using close button (that [X]) or like, you miss any validation code in your ondialogaccept handler...
My extensions: Save File to | ThumbsDown

TripleSix
 
Posts: 17
Joined: August 18th, 2007, 3:40 pm

Post Posted July 15th, 2008, 12:37 pm

Finally got some testers on the OSX case again, and the lack of an OK button is indeed fixed

However, the size of the prefwindow still is less than what it should be. As said, I've relocated my scripts behind all the prefpanes (bug 296418), but that didn't resolve it. Also, resizing on window onload doesn't work either..

Any other ideas to fix this weird OSX problem? or, if all else fails, is there a way to make this prefwindow resizable by the user?

ake79
 
Posts: 1336
Joined: February 17th, 2007, 6:05 am

Post Posted July 15th, 2008, 11:03 pm

Is this purely a Mac problem? Not Win or Linux? If it's either one of those also, I can take a look. But full .xpi please. I'm too lazy for some random snippets.

I doubt that anyone is able to help you much without seeing the code.

Don't know about re-sizing prefwindow. Never have had to rely on hacks like that.
My extensions: Save File to | ThumbsDown

potosino
 
Posts: 12
Joined: April 22nd, 2005, 9:16 am
Location: California, USA

Post Posted July 19th, 2008, 5:42 pm

TripleSix wrote:the size of the prefwindow still is less than what it should be

I've noticed this on Linux (Ubuntu) too. Has anybody found a solution?

TripleSix
 
Posts: 17
Joined: August 18th, 2007, 3:40 pm

Post Posted August 9th, 2008, 1:05 am

I think I've located the source of all problems- browser.preferences.animateFadeIn might be the guilty party here, a property thats true by default on Mac and linux systems, but not on Windows. It automatically resizes the prefwindow to fit the available content in the selected prefpane. It seems it gets confused somehow. But a possible solution might be to use identical box elements - fixed in height - to wrap around each prefpane, or at least to add some space at the bottom.

I haven't had time to try this myself yet (I even forgot about this thread 8-[), but it looks promising

ake79
 
Posts: 1336
Joined: February 17th, 2007, 6:05 am

Post Posted August 9th, 2008, 1:35 am

It seems to be |true| by default only in Mac.

http://mxr.mozilla.org/mozilla-central/ ... fox.js#508

I tested that pref in Linux and at least my two extensions' prefwindows draw just fine. It resizes when changing pane but all the widgets are visible.
My extensions: Save File to | ThumbsDown

TripleSix
 
Posts: 17
Joined: August 18th, 2007, 3:40 pm

Post Posted August 9th, 2008, 6:33 am

Ah, I sort of assumed it was also the case in Linux, because potosino also reported this problem above.. mea culpa :P

I've also tested this preference on Windows, and it renders just fine. But after some searching I've found other cases in which a dialog window is only partly visible, in the main firefox options dialog - mainly mac systems - and setting the browser.preferences.animateFadeIn preference to false was the proposed solution.

Of course, I can't force users of my extension to change this preference, but I can simulate it :)

Return to Extension Development


Who is online

Users browsing this forum: No registered users and 3 guests