| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
| |
(v1).
Tag UXP Issue #1344
|
|
|
|
|
|
| |
when possible.
Tag UXP Issue #1344
|
|
|
|
|
|
| |
CustomElementData.
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is in the observed attribute list.
We call attributeChangedCallback in two cases:
1. When any of the attributes in the observed attribute list has changed, appended, removed, or replaced.
2. When upgrading an element, for each attribute in element's attribute list that is in the observed attribute list.
Note: w/ Fixup for not implementing an API Enhancement Bug 1363481.
Tag UXP Issue #1344
|
|
|
|
|
|
|
| |
Per spec [1], we should include namesapce in attributeChangedCallback argurment list.
[1] https://html.spec.whatwg.org/multipage/custom-elements.html#concept-upgrade-an-element, step 3
Tag UXP Issue #1344
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
|
|
|
|
| |
document.registerElement() also works with construction stack.
So that the old upgrade can also work with new upgrade steps which will be implemented in part 5-2.
Tag UXP Issue #1344
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Tag UXP Issue #1344
|
|
|
|
|
|
| |
Note: Minus IPC bit.
Tag UXP Issue #1344
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
for custom elements;
Tag UXP Issue #1344
|
|
|
|
|
|
| |
a key;
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
|
|
|
|
| |
implementations.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
CheckForOutdatedParent()
This was only used to check for cases when document.open() changed the
global, and elements being inserted into the document needing a new
reflector as a result.
Since document.open() no longer changes the global, this code is no
longer needed.
|
| |
|
|
|
|
|
| |
The behavior change of document.open() requires these tests to be
changed to account for the new spec behavior.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the work we do for document.open() in the following ways:
- We no longer create a new Window when doing document.open().
We use the same Window but remove all the event listeners on the
existing DOM tree and Window before removing the document's existing
children to provide a clean slate document to use for .write().
- We no longer create a session history entry (previously would be a
wyciwyg URI). We now replace the current one, effectively losing the
entry for the original document.
- We now support document.open() on windowless documents.
|
|
|
|
|
|
|
|
|
| |
This updates our behavior for computed DOM styling to no longer return
null on elements that have no display, but return a 0-length (empty)
style instead and don't throw. For this we stop looking at having a
presentation for the style and just look at the document instead.
This resolves #1219
|
| |
|
|
|
|
|
| |
This can happen through DestroyElementMaps()
Based on work by Markus Stange and Edgar Chen.
|
|\
| |
| |
| |
| | |
# Conflicts:
# modules/libpref/init/all.js
|
| |\
| | |
| | | |
Support Modern Solaris
|
| | |
| | |
| | |
| | | |
This should do it for all the commits to files I changed, but while I'm in here I could probably go ahead and turn ALL the singular if defined statements into ifdef statements by using grep/find on the tree. On the other hand, perhaps we should do that as a separate issue so that this doesn't become a case of scope creep.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Compared with what Pale Moon had for Solaris originally, this is mostly the same zero point I started patching from, but I've made the following changes here after reviewing all this initial code I never looked at closely before.
1. In package-manifest.in for both Basilisk and Pale Moon, I've made the SPARC code for libfreebl not interefere with the x86 code, use the proper build flags, and also updated it to allow a SPARC64 build which is more likely to be used than the 32-bit SPARC code we had there.
2. See Mozilla bug #832272 and the old rules.mk patch from around Firefox 30 in oracle/solaris-userland. I believe they screwed up NSINSTALL on Solaris when they were trying to streamline the NSS buildsystem, because they started having unexplained issues with it around that time after Firefox 22 that they never properly resolved until Mozilla began building NSS with gyp files. I'm actually not even sure how relevant the thing they broke actually is to Solaris at this point, bug 665509 is so old it predates Firefox itself and goes back to the Mozilla suite days. I believe $(INSTALL) -t was wrong, and they meant $(NSINSTALL) -t because that makes more sense and is closer to what was there originally. It's what they have for WINNT, and it's possible a fix more like that could serve for Solaris as well. Alternatively, we could get rid of all these half-broken Makefiles and start building NSS with gyp files like Mozilla did.
3. I've completely cut out support for the Sun compiler and taken into account the reality that everyone builds Firefox (and therefore its forks) with GCC now on Solaris. This alone helped clean up a lot of the uglier parts of the code.
4. I've updated all remaining SOLARIS build flags to the newer XP_SOLARIS, because the SOLARIS flag is no longer set when building Solaris.
5. I've confirmed the workaround in gtxFontconfigFonts.cpp is no longer necessary. The Solaris people got impatient about implementing a half-baked patch for a fontconfig feature that wasn't ready yet back in 2009, and somehow convinced Mozilla to patch their software to work around it when really they should have just fixed or removed their broken fontconfig patch. The feature they wanted has since been implemented properly, and no version of Solaris still uses the broken patch that required this fix. If anyone had ever properly audited this code, it would have been removed a long time ago.
|
| | | |
|