Now, nobody requires nsIContentIterator interface. So, we can get rid of it.
Unfortunately, there is no macro to keep the inherited class,
ContentSubtreeIterator, in the cycle collection to make it keep managing
ContentSubtreeIterator::mRange without nsISupports interface. Therefore, this
patch moves it into ContentIteratorBase temporarily. Anyway, the following
patch makes those classes not refcountable. At that time, this issue will be
fixed.
Differential Revision: https://phabricator.services.mozilla.com/D15927
--HG--
extra : moz-landing-system : lando
Now, nobody requires nsIContentIterator interface. So, we can get rid of it.
Unfortunately, there is no macro to keep the inherited class,
ContentSubtreeIterator, in the cycle collection to make it keep managing
ContentSubtreeIterator::mRange without nsISupports interface. Therefore, this
patch moves it into ContentIteratorBase temporarily. Anyway, the following
patch makes those classes not refcountable. At that time, this issue will be
fixed.
Differential Revision: https://phabricator.services.mozilla.com/D15927
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This is ultimately the root cause of the issue. I'm landing a test to ensure we
notice the behavior change if we make it, in addition to a test for this issue
itself, to ensure that we don't get stuck, since after bug 1510485 we don't
return such nodes from nsFind when window.find is called anyway.
This code made no sense, it only returned true if the binding parent is the node
itself, which as far as I can tell cannot happen, so it was just a very
expensive way to return false.
Differential Revision: https://phabricator.services.mozilla.com/D14122
--HG--
extra : moz-landing-system : lando
Bug 1505887 changed the behavior here from content calling into nsFind via
window.find(), by making the SetStart and SetEnd calls here fail instead of
succeed for NAC (like the text in textareas).
This patch makes us handle that error gracefully moving on to the next match,
instead of trying to preserve the previous behavior.
This means that we'll fail to highlight textarea content and such from
window.find, which Chromium does, looks like. Though Chromium doesn't expose
the ranges as selection either. In any case I don't think that this is a very
common thing given bugs like bug 1442466, which this bug fixes.
I haven't found anything close to a spec for what window.find() should do... If
we decide to go with this patch then I'll add a crashtest for this and a test
for bug 1442466 as well. Otherwise I'll add a way to skip the security check in
nsFind somehow for NAC, or relax the security restrictions in SetStart /
SetEnd, I guess.
Differential Revision: https://phabricator.services.mozilla.com/D14013
--HG--
extra : moz-landing-system : lando
Turn all const lists and related attributes into cenums, to provide a
vague sense of type safety.
Depends on D11715
Differential Revision: https://phabricator.services.mozilla.com/D11716
--HG--
extra : moz-landing-system : lando
Calls to do_QueryInterface to a base class can be replaced by a static
cast, which is faster.
Differential Revision: https://phabricator.services.mozilla.com/D7224
--HG--
extra : moz-landing-system : lando
The general setup is that the State struct is used to iterate over text nodes
explicitly, and keeps references to the ranges so that we don't need to pass all
them around everywhere.
We need to teach nsFindContentIterator to rewind into NAC to be able to get rid
of mIterNode, which was getting out of sync when we failed to rewind to the
anchor node.
MozReview-Commit-ID: 5czYADrm1WX
We're throwing away the computation when aContinueOk is true, so we can remove
that call. Removing that call removes the last usage of aContinueOk, so remove
that handling as well.
This patch is idempotent.
MozReview-Commit-ID: E3sogickWp9
Instead of tweaking member variables and resetting them afterwards, just have an
object that we pass around.
This makes a bit easier to reason about nsFind IMO, and makes us able to use
more complex iterators that don't keep strong references to anything and that
kind of stuff, since we don't keep an iterator member around, and we don't
mutate the DOM from nsFind.
This patch is idempotent.
MozReview-Commit-ID: ERDnL6Q8QTU
We do reset them implicitly next time we call Find(..), since we call
ResetAll() at the beginning of it, then NextNode(..), which unconditionally
overrides them, but this is clearer for the next thing I want to do.
This patch is idempotent.
MozReview-Commit-ID: 6OW8MfkftTM
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
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
