| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
| |
There is a lot of string compare when using CSS property name. We should use nsGkAtoms instead.
Ref: Bug 1323138
|
| |
|
|
|
|
| |
EditorBase parameter of GetTextNode is unnecessary because it uses static method only. Also, we should return nsINode to reduce QI.
Resolves #1617
|
| |
|
|
|
|
|
|
| |
HTMLEditRules::MoveNodeSmart() with early return style for making scope of EditActionResult variable smaller
For now, let's make the scope of EditActionResult variable in them smaller without big change.
Tag #1563
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
which return nsresult, handled and canceled with out params
In a lot of places, edit action handlers and their helper methods return nsresult and aHandled and aCanceled with out params. However, the out params cause the code complicated since:
* it's not unclear if the method will overwrite aHandled and aCanceled value.
* callers need to create temporary variable event if some of them are not necessary.
This patch rewrites the helper methods of HTMLEditRules::WillDeleteSelection() with it.
Tag #1563
|
| |
|
|
|
|
|
|
|
|
| |
selection is collapsed and JoinBlocks() doesn't handle nor cancel the action
When selection is collapsed and JoinBlocks() doesn't handle nor cancel the action, WillDeleteSelection() should move selection to the start/end of leftmost/rightmost editable leaf node and retry to handle the action again.
For avoiding infinite loop, it checks if selected node is changed actually before calling itself again.
Tag #1563
|
| |
|
|
|
|
|
|
|
|
|
|
| |
HTMLEditRules::WillDeleteSelection() should have an out argument to indicates if it actually handles the action
When HTMLEditRules::WillDeleteSelection() tries to remove something from the end/start of a block to its last/first text node but it's contained by block elements, it tries to join the container and the block. However, JoinBlocks() always fails to join them since it's impossible operation. In this case, HTMLEditRules::WillDeleteSelection() should retry to remove something in the leaf, however, it's impossible for now because JoinBlocks() and its helper methods don't return if it handles the action actually.
This patch renames |JoinBlocks()| to |TryToJoinBlocks()| for representing what it is. And this patch adds |bool* aHandled| to the helper methods. Then, *aHandled and *aCancel are now always returns the result of each method. Therefore, for merging the result of multiple helper methods, callers need to receive the result with temporary variables and merge them by themselves.
Note that when they modify DOM node actually or the action should do nothing (for example, selection is across tables), aHandled is set to true.
Tag #1563
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This resolves #1517
|
| |
|
|
| |
Resolves #1514
|
| |
|
|
|
|
| |
This was refactored by Mozilla into doing effectively the same thing so
it aligns with them re: behavior.
Resolves #1513
|
| |
|
|
|
|
|
|
|
| |
IsSelectionEditable should check whether the focus node and anchor node
aren't null before trying to use them.
This also changes the initialization of selections' aOutIndex to the
last range in the selection as a fallback in case we don't add a range
later (in AddItem) which could also end up with a null selection
otherwise if the additional selection nodes are removed.
|
| |
|
|
| |
We can devirtualize it, remove some branches.
|
| |
|
|
| |
Tag #1343
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
EditorEventListener should grab mEditorBase in a smaller scope wherever possible and shouldn't access it directly while handling an event.
Each event listener method shouldn't access mEditorBase directly when calling its method since it might be changed to another instance.
|
| |
|
|
|
|
|
|
|
| |
call of editor's method.
EditorEventListener doesn't check if mEditorBase is available even after it's removed from the editor.
If it becomes nullptr, i.e., it's detached from editor, it shouldn't continue to handle event.
This patch changes some methods' nsIDOM*Event argument to WidgetEvent since it's simpler.
|
| | |
|
| | |
|
| |
|
|
| |
https://github.com/MoonchildProductions/moebius/pull/231
|
| |
|
|
| |
https://github.com/MoonchildProductions/moebius/pull/56
|
| |
|
|
|
|
| |
array to remove all descendants of replacement node
https://github.com/MoonchildProductions/moebius/issues/190
|
| |
|
|
| |
https://github.com/MoonchildProductions/moebius/pull/53
|
| | |
|
| |
|
|
| |
Edit transactions should store their editor instance with a strong reference, and they should be released when the editor is destroyed.
|
| |
|
|
| |
This fixes #6.
|
| |
|
