Right now, a XBL <constructor> runs before Custom Elements inside of its
<content> get upgraded. This leads to unexpected behavior where deck.selectedIndex = N
causes selectedIndex to get set as an expando property on the DOM node rather
than running the setter defined by the Custom Element.
Once the Custom Element does finally get upgraded, the selectedIndex getter and
setter don't get attached since there's an expando property with the same name.
This isn't a case we want to have to support from calling code. So this patch fixes
this one case by manually upgrading the element inside the constructor before
anything accesses the node. In Bug 1470242 we are planning to make this happen
behind the scenes so we don't need to do this for every CE inside of <content>.
MozReview-Commit-ID: 3D0QbOOJvDI
--HG--
extra : rebase_source : 1287445f2740dfe6a3ed5bdf273bb2b4b91b213c
... because these URIs are incompatible with TP.
We now show it on moz-extension: instead, which was forgotten previously.
This should probably have been in its own separate bug, but the changes in bug 1470020
surfaced this issue by throwing a lot of console errors when the baseURI was accessed,
so I didn't want to defer the fix.
MozReview-Commit-ID: 8KNV0oabv7Y
--HG--
extra : rebase_source : b6aae33385ed3166c59c0c8733de0a9609f05d92
We used to give this all the same "tracking-loaded" state, but now we want to differentiate between:
- Tracking loaded because TP is off
- Tracking loaded because of an exception
- Tracking not loaded but the site has an exception, which we want to allow the user to remove (if TP is on)
MozReview-Commit-ID: E9j0Roq1bsH
--HG--
extra : rebase_source : 70992e27b91bfed3cce0b868b63ce3a8c0afc5d0
UX found this confusing and unnecessary, after all.
MozReview-Commit-ID: DSBu8Xyo3YO
--HG--
extra : rebase_source : baec57bcb107cd8c6359aeeebc9bf2010116da7c
Right now, a XBL <constructor> runs before Custom Elements inside of its
<content> get upgraded. This leads to unexpected behavior where deck.selectedIndex = N
causes selectedIndex to get set as an expando property on the DOM node rather
than running the setter defined by the Custom Element.
Once the Custom Element does finally get upgraded, the selectedIndex getter and
setter don't get attached since there's an expando property with the same name.
This isn't a case we want to have to support from calling code. So this patch fixes
this one case by manually upgrading the element inside the constructor before
anything accesses the node. In Bug 1470242 we are planning to make this happen
behind the scenes so we don't need to do this for every CE inside of <content>.
MozReview-Commit-ID: LbXKKVeBYyQ
--HG--
extra : rebase_source : 83919106d1c43d7c8b960e4c1dd536e17e02f1f1
This is causing LSan leaks which don't have an easy fix, and we're
already not running it in debug builds, so it can't hurt too much.
MozReview-Commit-ID: I8nDnWIz9qr
--HG--
extra : rebase_source : 5f46c81aa31db81786941e86121f3dca532413ef
If discard is used immediately after creating a tab, restoring the tab
resulted in an unusable tab. This was due to the sessionstate not being
ready. This adds enough sessionstate to restore when this occurs.
MozReview-Commit-ID: 6PIc71BS8VU
--HG--
extra : rebase_source : 1bb9627eee561e9bf924e9eb2a34a5071cae3742
See Bug 1389251 comment 29 for full explanation of why we do this.
Also replaces ok(lines.length, value) with is(lines.length, value)
MozReview-Commit-ID: D4C3Aum9sfQ
--HG--
extra : rebase_source : d164764512640074d3d64d5dc4f86e193a9f26bc
This change makes nsEscape::T_EscapeURL not escape spaces when passed esc_OnlyNonASCII.
This fixes a web-compat issue for URLs such as "javascript: alert('hello');" and the fact that data: URIs with spaces around MIME type are rejected.
MozReview-Commit-ID: 91Qw9foW6Y3
--HG--
extra : rebase_source : 2da1b5f305ca2abcce2f9988cd6a5cbc12635c61
This should make it work for both remote and non-remote pages.
MozReview-Commit-ID: CpnGd0PoTGn
--HG--
extra : rebase_source : 5aec372dfcc4e7ba22cd16fa7eee15ed897a6fb7
