Maybe we should process pending XBL constructors before running parsed <script>

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
10 years ago
10 years ago

People

(Reporter: bzbarsky, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
From an old-ish email thread:

  In this case the XBL is actually a chrome binding (so does load sync)
  attached to an HTML node (so not a XUL document).  It changes the "submit"
  property of a form so as to catch programmatic submits of that form (in
  addition to hooking onsubmit to catch user-generated ones).  The relevant
  part of the HTML of the page in question is more or less like this:

  <body>
    <form>
      <object><!--This is the bound node--></object>
    </form>
  </body>
  <script>
    // Submit form here
  </script>

  Maybe we should consider calling PAQ before executing scripts?

Note that on trunk we run the constructor from EndUpdate anyway, so before the script, so this would be a belt-and-suspenders kind of thing if we decide to still do it.  Jonas thought this was a good idea, but I'm not sure whether we still need to worry at this point.
Yeah, unless there's a specific reason to, I think I'd prefer not to mess with it.

I wonder if we'd get weird behavior if for example an XBL constructor created an inline <script> using the DOM and inserted it.
(Reporter)

Comment 2

10 years ago
Could be...  I just figured I'd get this filed and out of my inbox is all.  ;)
Ok, lets mark this WONTFIX for now then
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.