Using `nsISecretDecoderRing` directly bypasses
`nsILoginManagerCrypto.uiBusy` and the observer notifications, so other
consumers might not be aware we're already showing the dialog. We also
bail early if the UI is busy, to avoid showing multiple dialogs.
MozReview-Commit-ID: I7xzUWZkyPH
--HG--
extra : rebase_source : 91cef140cc54d1c81fe5c1986ffd2b8983ddd575
Currently, RangeBoundaryBase can store either only mRef or mOffset. However,
== operator of RangeBoudaryBase still compares mRef simply. However, if one
has only mRef and the other has only mOffset, it returns false.
This patch makes == operator checks if both mOffset have been set. If so,
this checks both mOffset.value() and mRef are matched. However, if mRef of
only one of them is nullptr, this doesn't make it check mRef because computing
mRef needs some cost and initializing mRef from the other fixes the referring
child stronger. If the user of the operator sets only mOffset and wait DOM
tree changes, computing mRef may break such callers.
If one has only mRef and the other has only mOffset, this patch makes it
compute mRef. This is not the best behavior, perhaps. However, there is no
way to compare these instances. If this becomes a problem, we should make it
create temporary instance, but it'll waste runtime cost. So, let's avoid using
this approach for now.
Finally, making it check both mRef simply.
MozReview-Commit-ID: 4nsW5SYDTiZ
--HG--
extra : rebase_source : b16ec01bdefc8fd847fc43513581aeb0efbf4e21
This crash test can cause crash before landing the patches for bug 1415509.
So, let's take this for regression test.
MozReview-Commit-ID: 652wi49e720
--HG--
extra : rebase_source : a7a897670220e4f14df91c4093e65aa7da7f6015
First, the method name is not correct. It tries to find an editable node near
the given DOM point. Therefore, it should be FindNearEditableNode().
Next, the implementation did something odd. E.g., in the first |if| block,
when |nearNode| is nullptr, it returns nullptr. However, following |if| block
does something only when |nearNode| is nullptr. So, we can get rid of the
second |if| block. Then, nobody will change aDirection. So, we can make it
not a reference now.
Similarly, in |while| block, if |nearNode| becomes nullptr, it returns error.
However, following block checks if |nearNode| is NOT nullptr. So, we can get
rid of this |if| statement and outdent its block.
Additionally, |curNode| isn't necessary. It only increments the refcount
redundantly. So, we can get rid of it.
Finally, FindNearEditableNode() can return found node directly instead of
error code because error code doesn't make sense. Not found an editable
node is not illegal. And also it can take EditorRawDOMPoint instead of
a set of container, child and offset of the child in the container.
MozReview-Commit-ID: CTI581PhJMd
--HG--
extra : rebase_source : 7e05998721ce96727d40dda1be5e7e36b090bcd3
HTMLEditor::GetNextHTMLNode() should be redesigned as
HTMLEditor::GetNextEditableHTMLNode(nsINode&),
HTMLEditor::GetNextEditableHTMLNodeInBlock(nsINode&),
HTMLEditor::GetNextEditableHTMLNode(const EditorRawDOMPoint&) and
HTMLEditor::GetNextEditableHTMLNodeInBlock(const EditorRawDOMPoint&).
Same as GetPreviousEditableHTMLNode*(), we don't need the methods to find
non-editable nodes too.
MozReview-Commit-ID: JjZauCMblp4
--HG--
extra : rebase_source : 1e650d79bc21d7f920b3f46f4a2f208ac23cc0a6
HTMLEditor::GetPriorHTMLNode() methods are similar to EditorBase::GetPriorNode()
which was redesigned with the previous patch.
So, it should be redesigned as
HTMLEditor::GetPreviousEditableHTMLNode(nsINode&),
HTMLEditor::GetPreviousEditableHTMLNode(const EditorRawDOMPoint&),
HTMLEditor::GetPreviousEditableHTMLNodeInBlock(nsINode&) and
HTMLEditor::GetPreviousEditableHTMLNodeInBlock(const EditorRawDOMPoint&).
Note that HTMLEditor::GetPriorHTMLNode() are always return editable node.
So, we don't need to create non-editable node methods for them.
Although, I don't like the word "HTMLNode" because this can return SVG element
or something too. The additional feature of those methods is just checking
given node is in active editing host. So, they are for HTML editor, but not
returning only HTML nodes. However, I have no better idea with shorter name.
MozReview-Commit-ID: 3J4IaBOFjzj
--HG--
extra : rebase_source : 712bc8676fcdc37f38fd46083df177c0fe6bd408
An overload of EditorBase::GetNextNode() takes a set of container, child node
and offset of the child in the container. Replacing it with EditorRawDOMPoint
makes the caller simpler.
Additionally, it has two bool arguments, one is for searching if editable node,
the other is for searching if in same block. So, they can be hidden with
some human readable inline methods.
When I was creating this patch, I realized that
GetNextNodeInternal(const EditorRawDOMPoint& aPoint) may return
aPoint.GetChildAtOffset(). I.e., it starts to search from the specified point
rather than next node. On the other hand, GetNextNodeInternal(nsINode& aNode)
never returns aNode itself. So, it there is better name instead of "Next",
we should take it. But I have no better idea. So, this patch just explains
the difference with comments in EditorBase.h.
MozReview-Commit-ID: 4Lb6o9SJuhy
--HG--
extra : rebase_source : d20d728eae69659ef448b6679ae8f73d64c2d7e9
An overload of EditorBase::GetPriorNode() takes a set of container, child node
and offset of the child in the container. Replacing it with EditorRawDOMPoint
makes the caller simpler.
Additionally, it has two bool arguments, one is for searching if editable node,
the other is for searching if in same block. So, they can be hidden with
some human readable inline methods.
Finally, "Prior" isn't a term of DOM. So, let's use "Previous" instead.
MozReview-Commit-ID: A9uKzHaikY9
--HG--
extra : rebase_source : 15bfdfde0ad89a5331d6c8a24351741eeef476d5
Like EditorBase::InsertTextImpl(), WSRunObject::InsertText() is really messy.
So, it should take same arguments as EditorBase::InsertTextImpl().
MozReview-Commit-ID: 5uKGaxKheRv
--HG--
extra : rebase_source : 49ce0eb7ea25b397b6b1a19f1bc21d711740c043
EditorBase::InsertTextImpl() takes |nsCOMPtr<nsINode>*|, |nsCOMPtr<nsIContent>*|
and |int32_t| as in/out arguments for container, child and offset of the child
in the container. But this makes the callers really hard to read and ugly.
So, we should make the method take |const EditorRawDOMPoint&| argument as input
and |EditorRawDOMPoint*| as out argument.
MozReview-Commit-ID: 2ijIfGl4Zo7
--HG--
extra : rebase_source : b309d9bdc04aac620f138769ba18ad7e4597fe6c
EditorBase::FindBetterInsertionPoint() now use 3 in/out arguments. This is
really ugly and making the callers hard to read. So, let's make it take an
argument whose type is |const EditorRawDOMPoint&| and return other
EditorRawDOMPoint instance.
Additionally, this fixes bugs of text node length checks in the method.
Basically, this shouldn't affect to any actual behavior, though. That is
because text node shouldn't be able to have string longer than INT32_MAX.
MozReview-Commit-ID: FClUQSJzd8c
--HG--
extra : rebase_source : 3e2fbd345015f7068c7e35a94c31731e7936009f
Because we need the parseContent function return "document fragment" or "div" or "pseudo cue div" or "pseudo region div" ...
It's better to use enumerate instead boolean flag.
MozReview-Commit-ID: 5zmwXiYreqS
--HG--
extra : rebase_source : 57706a7fbf36b2c65fa93362dbfbf9a30d2d7418
Bug 1108587 seems to suggest that the grace period for nsTerminator is
too short for ASAN builds, which take much longer to shutdown. This
patch changes the grace period from 1 minute to 3 minutes, hoping that
this will be sufficient. Somewhere along the way, we also extend the
duration of AsyncShutdown, because that's the simplest way to do both
at once.
MozReview-Commit-ID: 28eWO5m6Wh3
--HG--
extra : rebase_source : eae9db952d5395f986781f3cbd23507b715fa8c9
Currently, huge allocations are completely independent from arenas. But
in order to ensure that e.g. moz_arena_realloc can't reallocate huge
allocations from another arena, we need to track which arena was
responsible for the huge allocation. We do that in the corresponding
extent_node_t.
Both functions do essentially the same thing, one having more validation
than the other. We can use a template with a boolean parameter to avoid
the duplication.
Furthermore, we're soon going to require, in some cases, more
information than just the size of the allocation, so we wrap their
result in a helper class that gives information about an active
allocation.
These low level docs are getting out of date and causing confusion. Further,
they are of limited value at this stage anyway.
MozReview-Commit-ID: FSoNniNZjtj
--HG--
extra : rebase_source : fa5e02a771adcae9b0e53bd18c4eb10ebb5315ef
Daosheng Mu
Nevin Chen
Kit Cambridge
James Cheng
Masayuki Nakano
Miko Mynttinen
bechen@mozilla.com
David Teller
Noemi Erli
Margareta Eliza Balazs
Phil Ringnalda
Sebastian Hengst
Mike Cooper
Matt Woodrow
Mike Hommey
Tommy Kuo
ffxbld
Andreea Pavel
J. Ryan Stinnett
dluca