Closed Bug 58757 Opened 24 years ago Closed 7 years ago

<script> tags in XBL document


(Core :: XBL, defect, P3)






(Reporter: aaronlev, Unassigned)



(Keywords: embed, Whiteboard: [XBL1.0])

This is part of work needed for XBL 1.0
better still, we need this for embedding DnD work
Blocks: 45605
Severity: enhancement → blocker
Keywords: embed, mozilla0.9
->moz0.8, although there is no hard requirement for embedding D&D yet.
Target Milestone: --- → mozilla0.9
meant .9 as targetted, move to .8 if we get a short-term requirement.
shouldn't be blocking now, ->future
Target Milestone: mozilla0.9 → Future
Whiteboard: [XBL1.0]
Target Milestone: Future → mozilla1.1
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?
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.
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
1.1 alpha's long gone.  Retarget?
Severity: blocker → normal
Target Milestone: mozilla1.1alpha → ---
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.

May be I can help with something?
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.

There is a hack i use that works.

js code below is just sample code.

     var mXOffset, mYOffset;
     var mWin=null;
     var mWinCont=null;

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

Play around your mileage may vary.               
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.
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">
            var accService =
            return accService.createXULTabBoxAccessible(this);

      <property name="_tabs">
          var tabs = this.getElementsByTagNameNS(
          return tabs.length ? tabs[0] : null;

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

        this._eventNode.addEventListener("keypress", this._keyEventHandler, false);

        this._eventNode.removeEventListener("keypress", this._keyEventHandler,

      <method name="advanceSelectedTab">
        <parameter name="aDir"/>
          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
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?
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.
*** Bug 236994 has been marked as a duplicate of this bug. ***
Anyone have any starter tips on how to implement this? I assume hyatt has no plans to work on this any more?
QA Contact: jrgmorrison → xbl
Assignee: hyatt → nobody
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.
Blocks: XBL2
Web Components \o/
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.