| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
| |
There are two places doing prototype setup in old upgrade,
- If definition comes after JS reflector creation, CustomElementRegistry::Upgrade will do prototype swizzling.
- If definition comes before JS reflector creation, Element::WrapObject will set up the prototype.
The later one does SubsumesConsideringDomain, but the former doesn't not.
This patch is to fix the inconsistency, i.e. the former case should also do SubsumesConsideringDomain.
Tag UXP Issue #1344
|
|
|
|
|
|
|
|
| |
1. It is possible that invoking a reaction triggers pushing a new ElementQueue into ReactionStack (e.g., calling define() in constructor which probably enqueue another upgrade reaction), and the reference of ElementQueue passed to InvokeReactions becomes invalid due to the memmove in nsTArray implementation.
2. And we get another benefit from this is memmove becomes faster.
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
|
|
| |
Note: Skipped SyncInvokeReactions since it is removed in CE v1, waste of time.
Tag UXP Issue #1344
|
|
|
|
|
|
| |
re-enter CustomElementReactionsStack::InvokeReactions.
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
|
|
| |
virtual;
Tag UXP Issue #1344
|
|
|
|
|
|
|
|
| |
of using a map;
Bug 1347446 makes accessing ElementReactionQueue becomes a bit non-trival (have to get it via DocGroup). Since bug 1359346 already refactors the creation time of CustomElementData, ReactionQueue can also be put into CustomElementData, then we can just get ReactionQueue from Element.
Tag UXP Issue #1344
|
|
|
|
|
|
|
|
| |
registered first shouldn't throw NotFoundError;
per spec change: https://github.com/w3c/webcomponents/issues/608
Tag UXP Issue #1344
|
|
|
|
|
|
| |
https://dom.spec.whatwg.org/#concept-element-custom-element-state
Tag UXP Issue #1344
|
|
|
|
|
|
| |
feature is pref-ed off;
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
|
|
| |
Note: Minus IPC bit.
Tag UXP Issue #1344
|
|
|
|
|
|
| |
code.
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
|
|
| |
to generate CEReaction code.
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
|
|
|
|
| |
DocGroup is going away.
Note: In UXP we use non-Quantum thread checking implementation here.
Tag UXP Issue #1344
|
|
|
|
|
|
| |
propagate out JS exceptions;
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
|
|
| |
CustomElementRegistry;
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
|
|
| |
for custom elements;
Tag UXP Issue #1344
|
|
|
|
|
|
| |
nsHTMLTagList.h;
Tag UXP Issue #1344
|
|
|
|
|
|
| |
a key;
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two changes here:
1) We allow setting .body even if the root element is not an <html:html>. This is what the spec says to do, and what we used to do before the changes in bug
366200. No tests for this yet, pending https://github.com/whatwg/html/issues/3403 getting resolved.
2) We use GetBody(), not GetBodyElement(), to look for an existing thing to replace. This matters if there are <frameset>s involved.
Tag UXP Issue #1344
Tag UXP Issue #252
|
|
|
|
|
|
|
| |
nsHTMLDocument to nsIDocument.
Tag UXP Issue #1344
Tag UXP Issue #252
|
|
|
|
|
|
|
| |
nsHTMLDocument to nsIDocument.
Tag UXP Issue #1344
Tag UXP Issue #252
|
|\
| |
| | |
Potential hang on bad FTP sequence
|
| | |
|
|/
|
|
|
|
| |
LIST and RETR still appear to work as intended on ftp:// URLs after my changes. I wasn't able to test STOR because the browser doesn't appear to support FTP uploads at this time (although our FTP implementation appears perfectly capable of doing an FTP upload.)
If I understood the issue correctly, though, what we're doing is ensuring that we receive a preliminary 100 response from the FTP server for a given action before jumping to the 200 code describing what we do if the action was completed. Even though it makes no logical sense for a server to say an action was completed before it was initiated, someone could write a really annoying FTP server that takes advantage of this fact to crash the browser if they wanted.
|
|
|
|
| |
MOZ_MEMORY is defined (which is defined by enabling jemalloc in config)
|
|
|
|
| |
This rewrites the caching mechanism to apply to both PBKDF1 and PBKDF2
|
| |
|
|
|
|
| |
implementations.
|
|\
| |
| |
| | |
(merge of gl-work branch)
|