<script> tags in XBL document

RESOLVED WONTFIX

Status

()

Core
XBL
P3
normal
RESOLVED WONTFIX
17 years ago
3 months ago

People

(Reporter: Aaron Leventhal, Unassigned)

Tracking

({embed})

Trunk
All
Other
embed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [XBL1.0])

(Reporter)

Description

17 years ago
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

Comment 2

17 years ago
->moz0.8, although there is no hard requirement for embedding D&D yet.
Target Milestone: --- → mozilla0.9

Comment 3

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

Comment 4

17 years ago
shouldn't be blocking now, ->future
Target Milestone: mozilla0.9 → Future

Updated

17 years ago
Status: NEW → ASSIGNED
Whiteboard: [XBL1.0]
Target Milestone: Future → mozilla1.1

Comment 5

16 years ago
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

16 years ago
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

15 years ago
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?
1.1 alpha's long gone.  Retarget?

Updated

15 years ago
Severity: blocker → normal
Target Milestone: mozilla1.1alpha → ---

Comment 9

15 years ago
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?
(Reporter)

Comment 10

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

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

15 years ago
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.
(Reporter)

Comment 13

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

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

Updated

8 years ago
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.
Status: ASSIGNED → NEW

Updated

6 years ago
Blocks: 374737

Comment 19

3 months ago
Web Components \o/
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.