58757 - <script> tags in XBL document

Status: RESOLVED WONTFIX

(Core :: XBL, defect, P3)

Description

[Aaron Leventhal]

This is part of work needed for XBL 1.0

Comment 1

[Mike Pinkerton (not reading bugmail)]

better still, we need this for embedding DnD work

Comment 2

[Peter Trudelle]

->moz0.8, although there is no hard requirement for embedding D&D yet.

Comment 3

[Peter Trudelle]

meant .9 as targetted, move to .8 if we get a short-term requirement.

Comment 4

[Peter Trudelle]

shouldn't be blocking now, ->future

Comment 5

[Stuart Ballard]

This is blocking me xblifying the link toolbar, unless somebody can come up with
a better workaround than using the jssubscript-loader. See recent thread in
n.p.m.xbl (and I've also had irc discussions about it in which nobody's been
able to give me a workaround). The problem is that my js file is shared with
other code so I can't just turn it into a binding - that would mean duplicating
it's content.

Are there any plans to implement this soon? Does anyone know of a workaround? Or
would it actually be acceptable to use jssubscript-loader in the linkToolbar?

Comment 6

[Robert Ginda]

I'm very much in favor of seeing this make mozilla1.0.

Hyatt, I don't understand the security concerns you allude to in bug 45605.  If
we've got a context for the embedded xbl scripts, why can't we
JS_CompileScript() source from an external file on it?

Is asynchronous loading going to be an issue?

I'd be willing to settle for an <xbl:script> restricted to chrome: files for
1.0.    If it didn't get too involved, I'd probably even do it.

Comment 7

[Martin Kutschker]

Robert, restricting script to chrome is not "acceptable". Without scripts
Mozilla is not on par with IE.

In theory you can have cross browser "behaviors" to beef up your HTML pages if
you share script for a .XBL and a .HTC file. This works if you're content with
including script tags in the host page. But it is clumsily.

Is there any hope we get this into Mozilla 1.2? What needs to be done? How can I
help?

Comment 8

[Alex Vincent [:WeirdAl]]

1.1 alpha's long gone.  Retarget?

Comment 9

[Maksim Likharev]

This one blocks ( at least for us ) development of cross browser content,
without embended script XBL just a useless cute toy.
I would put all my Votes on this.

P.S
May be I can help with something?

Comment 10

[Aaron Leventhal]

Maksim, are you sure there aren't other ways to do the code reuse you need? You
can create methods on an xbl object and use that, it's just as effective. Or,
create a service and use that from xbl -- similar to how nsIAccessibilityService
is used in xbl.

Comment 11

[Pete Collins (MDG)]

There is a hack i use that works.

js code below is just sample code.

 <implementation>
   <![CDATA[
     var mXOffset, mYOffset;
     var mWin=null;
     var mWinCont=null;
   ]]>
 </implementation>      

I found that the vars declared are accessible to other methods in the
implementation.

Play around your mileage may vary.               

Comment 12

[Maksim Likharev]

Aaron,
sure there are different ways to workaround that, 
like put all code into js file or even as radical as killing all 
our IE behaviors and put/do everything in js, 
but one of the reasons why I think XBL is good, following:
similar idea as IE behaviors and more important that rest of the code 
will stay the same/almost the same 
( except of cause of duplicating code in XBL ) so a huge win.
Using all that hacks in order to somehow support global variables/code, just 
don’t wanna do that, may not work later, anyway just hope that will be 
fixed/implemented soon enough.
Thank you for advice.

Comment 13

[Aaron Leventhal]

I would use something more like this, which is not a hack at all -- it's the way
things are done in XBL:

    <implementation implements="nsIAccessibleProvider">
      <property name="accessible">
        <getter>
          <![CDATA[
            var accService =
Components.classes["@mozilla.org/accessibilityService;1"].getService(Components.interfaces.nsIAccessibilityService);
            return accService.createXULTabBoxAccessible(this);
          ]]>
        </getter>
      </property>

      <property name="_tabs">
        <getter>
        <![CDATA[
          var tabs = this.getElementsByTagNameNS(
              "http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul",
              "tabs");
          return tabs.length ? tabs[0] : null;
        ]]>
        </getter>
      </property>

      <field name="_keyEventHandler" readonly="true">

      <constructor>
        this._eventNode.addEventListener("keypress", this._keyEventHandler, false);
      </constructor>

      <destructor>
        this._eventNode.removeEventListener("keypress", this._keyEventHandler,
false);
      </destructor>

      <method name="advanceSelectedTab">
        <parameter name="aDir"/>
        <body>
        <![CDATA[
          var startTab = this.selectedItem;
          var next = startTab[aDir == -1 ? "previousSibling" : "nextSibling"];

          while (next != startTab && (!next || next.getAttribute("hidden"))) {
            if (next && next.getAttribute("hidden"))
              next = next[aDir == -1 ? "previousSibling" : "nextSibling"];
            if (!next)

...

The constructor, destructor, properties, methods and fields and access to the
service provider/ component manager should give you everything you need.

Look at Mozilla's XBL files for more examples -- for example the code in
xpfe/global/resources/content/bindings/*.xml

Comment 14

[Alex Vincent [:WeirdAl]]

petejc: your hack in comment 11 looks like it violates scope as JavaScript
Engine sees it.  

rginda: do you think that is a bug we should file separately?

Comment 15

[Pete Collins (MDG)]

Sure does, you'll see lots of warnings if you run in strict mode. I don't
recommend doing this. It is wrong. I've been using properties w/ getters and
setters to hold variable values but is just seems silly you have to do it that way.

Using properties for member variables you really don't want exposed publicly to
clients but have no other real choice adds bloat and confusion in the widgets
construction. Where a <script> tag is really what you want.

<script> whout acces to xpconnect is fine if security us an issue.

Comment 16

[Boris Zbarsky [:bzbarsky]]

*** Bug 236994 has been marked as a duplicate of this bug. ***

Comment 17

[Jonathan Watt [:jwatt]]

Anyone have any starter tips on how to implement this? I assume hyatt has no plans to work on this any more?

Comment 18

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 19

[Anne (:annevk)]

Web Components \o/