526692 - implement jetpack.settings.open for opening settings programmatically

Status: RESOLVED WONTFIX

(Mozilla Labs :: Jetpack Prototype, defect, P1)

Description

[Myk Melez [:myk] [@mykmelez]]

Per JEP 24, it should be possible for jetpacks to open their own settings interfaces programmatically by calling jetpack.settings.open.  This is currently complicated, as settings open inside about:jetpack, about:jetpack might not be open, and opening it causes jetpacks to get reloaded, including the one that made the call and whose state may need to be preserved across reload.

The issue with about:jetpack reloading jetpacks is supposedly going to get resolved at some point, but regardless, we should probably have a way to open settings outside of about:jetpack, perhaps in a chrome panel inside the main chrome window.

Comment 1

[Aza Raskin [:aza]]

Ah, the restart. That's the problem.

Once we have panels, then it should be easy to open up the settings in an exteral chrome panel?

Comment 2

[Myk Melez [:myk] [@mykmelez]]

Perhaps, although we don't need the panels feature in order to implement this.

Comment 3

[Aza Raskin [:aza]]

In that case, I think the fix of opening up the settings in it's own panel should be on the list of things to do for 0.7 (or before). That will make settings useful and used.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Attachment: work in progress

Here's a work in progress that partly implements this feature.  It opens settings in a XUL panel within the browser window.  Display of the settings partly works, but jQuery UI style isn't being applied, and dragging a slider doesn't work (it sometimes throws an exception that indicates jQuery expects a body element in the document).

It's probably possible to work out the issues with jQuery in XUL, although it might be easier and more robust to embed the view within a chrome iframe inside the XUL panel.  Atul has mentioned that he experienced focus problems doing that with an unrelated project, however.

Comment 5

[Daniel Buchner [:dbuc]]

I hacked on Mootools Core once for similar XUL issues, I don't think the jQuery stuff would be hard to fix. What would really be cool is to be able to redux these DOM dependency hurdles and hand them out to the library authors for elimination... 

I had some experience before coming here with this sort of thing, perhaps we can preempt some of these js lib compatibility snafus...

Comment 6

[Brian King [:kinger]]

(In reply to comment #4)
> It's probably possible to work out the issues with jQuery in XUL, although it
> might be easier and more robust to embed the view within a chrome iframe inside
> the XUL panel.  Atul has mentioned that he experienced focus problems doing
> that with an unrelated project, however.

See bug 385609, in particular comment 6.

Comment 7

[Matěj Cepl]

continuation from bug 536780:

Also, two more comments on the settings generally:

- some [OK], [Submit], [Close] button would be helpful ... closing a dialog by
clicking on the top-right corner is in my books "close without changing
anything".
- in about:jetpack those jetpacks which shouldn't have any settings (i.e., no
manifest) shouldn't have the settings link

Also, but if I try this minimalist example
(http://www.ceplovi.cz/matej/jetpack/install-test-settings.html), then dialog
opens all right, but then I get error

"chrome://jetpack/content/index.html ->
http://www.ceplovi.cz/matej/jetpack/jetpack-settings.js"
lineNumber    22
message    "jetpack.settings is undefined"
name    "TypeError"
stack    "@chrome://jetpack/content/index.html -> \
   http://www.ceplovi.cz/matej/jetpack/jetpack-settings.js:22\n"

Comment 8

[Matěj Cepl]

using jetpack 0.7 on Linux/x86_64

Comment 9

[Myk Melez [:myk] [@mykmelez]]

Matej: thanks for the reports!  I really appreciate them.  However, Bugzilla works best when each bug has its own report, because then we can track and resolve each one individually.

Regarding an Ok or Close button, I filed that as bug 539129, included some thoughts, and cc:ed Aza for his thoughts.

Regarding the Settings button for features without settings, that was bug 526695, where I decided to disable the button instead of hiding it (admittedly the current disabled styling could use some improvement, as could the enabled style for that matter!).

Regarding the "jetpack.settings is undefined" error, unfortunately jetpack.settings is not implemented yet!  That's what this bug is all about.  So that's currently expected behavior, unfortunately.

Comment 10

[Matěj Cepl]

I am sorry, I should know better, and thank you very much for the quick response (and filing the bug).

Comment 11

[Myk Melez [:myk] [@mykmelez]]

Attachment: work in progress 2

Here's another work in progress.  In this patch, I switched to building the settings view inside a chrome iframe inside a XUL panel, since getting the jQuery-dependent view working in an HTML document inside a panel seems easier than getting jQuery working in a XUL document.

The big blocker is that events aren't reaching the various elements in the view.  As folks have noted in earlier comments, this is a known problem.  I wonder if it's actually the same problem that was recently solved for content iframes inside XUL panels (bug 533845).

If so, and if (as seems likely) that patch lands in 1.9.2.1, then we could actually get this working for Firefox 3.6.1.

(Besides that blocker, the other piece still to be done is to position the panel appropriately; right now we arbitrarily position it 50 pixels down and over from the top-left corner of the browser.)

Comment 12

[Daniel Buchner [:dbuc]]

We will be monitoring all these issues after the rebooted Jetpack code base is released in the first week of March to ensure their causes are not duplicated. Many of the bugs/issues with the prototype version of Jetpack will be made irrelevant given the structure of the new SDK.