This fixes browser/components/extensions/test/browser/file_find_frames.html with
my patches. We were relying on traversing suppressed whitespace to match the
whole word properly there.
You can see the bug with the following test-case:
<p>Banana 0</p><p>Banana 1</p>
If you try to match "banana" using "Whole word", you'll only find the first
word, because we keep c = '0'. If there's a newline between the two paragraphs,
like in the test, before my patch we we would traverse it (even though it's
suppressed whitespace) and keep c = '\n', which makes the match succeed.
Fix it forgetting the state of the match completely, including c.
That test was firing a lot of "GetOffsetTo() called on frames from different
documents" assertions... That's probably worth looking into as a followup.
MozReview-Commit-ID: AzId7YWQcJI
I ended up not using the nsIFrame methods both for consistency with the plain
text serializer and because of include hell due to nsStyleStructInlines /
nsIFrameInlines.
Find doesn't care about nodes with no frames anyway, so it didn't seem worth
doing the fallback if there's no style information.
I'll file a bug for IsHTMLBlock.
MozReview-Commit-ID: 3T317a4xCB
This fixes browser/components/extensions/test/browser/file_find_frames.html with
my patches. We were relying on traversing suppressed whitespace to match the
whole word properly there.
You can see the bug with the following test-case:
<p>Banana 0</p><p>Banana 1</p>
If you try to match "banana" using "Whole word", you'll only find the first
word, because we keep c = '0'. If there's a newline between the two paragraphs,
like in the test, before my patch we we would traverse it (even though it's
suppressed whitespace) and keep c = '\n', which makes the match succeed.
Fix it forgetting the state of the match completely, including c.
That test was firing a lot of "GetOffsetTo() called on frames from different
documents" assertions... That's probably worth looking into as a followup.
MozReview-Commit-ID: AzId7YWQcJI
I ended up not using the nsIFrame methods both for consistency with the plain
text serializer and because of include hell due to nsStyleStructInlines /
nsIFrameInlines.
Find doesn't care about nodes with no frames anyway, so it didn't seem worth
doing the fallback if there's no style information.
I'll file a bug for IsHTMLBlock.
MozReview-Commit-ID: 3T317a4xCB
This method is not a virtual call, and also looks nicer.
This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.
MozReview-Commit-ID: 8JExxqSRc59
--HG--
extra : rebase_source : df6330a89e8d65dfe7a6fda0c8cb9f9732302efc
I got a bit carried away with fixing up consumers to use nsINode... But as a
result removing these methods all together made sense.
MozReview-Commit-ID: 2z9Q6D7GY92
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This patch adds an overload to nsIContentIterator::Init which accepts
RangeBoundary objects, and modifies the codepath to avoid using the offset of
the start or end nodes to construct the nsIContentIterator.
MozReview-Commit-ID: 5ZqKeiUunoN
With previous change, KeyboardEvent is dispatched even when invisible window
has focus. However, nsRootWindow::GetControllerForCommand() returns controller
for focused window even when the window is invisible because it uses
nsFocusManager::GetFocusedDescendant() to retrieve focused window.
Perhaps, we can assume that users won't expect to do something with invisible
window when they type some keys. Then, nsRootWindow::GetControllerForCommand()
should return controller for visible ancestor window if focused window is
invisible.
This patch makes nsFocusManager::GetFocusedDescendant() can return only visible
descendants. However, it already has a bool argument. Therefore, it should
have a flag instead of adding new flag. Most changes of this patch is replacing
its callers.
Then, nsRootWindow::GetControllerForCommand() and nsRootWindow::GetControllers()
should have a bool flag if it should return controller(s) for visible window.
This patch adds a bool flag for it. Fortunately, the interface isn't scriptable.
Finally, this patch makes nsXBLPrototypeHandler::DispatchXBLCommand() and
EventStateManager::DoContentCommandEvent() retrieve controller for visible
window since they are always handles user input.
MozReview-Commit-ID: GygttTHuKRm
--HG--
extra : rebase_source : 1341273c4606298cb9b890b9312d9f5c8a75d144
nsIContentIterator::Init() takes nsRange but it's too expensive for some users.
So, there should be another Init() which can be specified a range in DOM tree
with 2 pairs of nsINode* and uint32_t.
MozReview-Commit-ID: 6JXic0KOM2d
--HG--
extra : rebase_source : 28ff355a2aa0dcb5d65495806ef8c67f1da642ea
This is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
DOM Standard defines that offset of Range is unsigned long. However, nsRange uses int32_t to them.
This patch makes nsRange use uint32_t instead. However, this patch does NOT allow to set over INT32_MAX as offset values since a lot of users of nsRange cannot treat the values as over INT32_MAX because a lot of internal APIs take int32_t as offsets.
For easier to search such points, this patch adds static_cast<int32_t> to uint32_t variables when they are used for int32_t arguments.
And note that nsContentUtils::ComparePoints() behaves odd. It accepts negative offset and compares such value with valid offset simply. This patch still uses int32_t offset variables in nsRange::CompareNodeToRange() even though it may be negative value if nsINode::IndexOf() returns -1 because the caller of it depends on this behavior.
MozReview-Commit-ID: 8RbOgA86JuT
--HG--
extra : rebase_source : 46d526c6d50dfa2f104439b19b8691477b17a4af
