Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
--HG--
extra : rebase_source : 148555189f73fb29a48296215e367c406f3f0286
* Test helpers for cards
* Refactor the test_add_link test to test in private & non-private window
MozReview-Commit-ID: AeVJOkSwQps
--HG--
extra : rebase_source : 6e8380826bcac87bc408ff75a6a398b5c4f6cafa
* addSampleAddressesAndBasicCard now accepts arrays of addresses and card, but with no args defaults to its original behavior
* addAddressRecord and addCardRecord helpers
* New helpers for each step in the sequence of clicking through to add a new address
MozReview-Commit-ID: Dto5MSekJTV
--HG--
extra : rebase_source : be32c684dba62d051bb119a530437830e41bb128
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