Open GoogleCodeExporter opened 9 years ago
This is in fact an issue. It also happens when switching SearchWP's
highlighting on/off (without switching the tab, switching the tab actually
triggers re-highlighting internally which is issue 65)
Basically SearchWP's highlighting does not play well with Firefox's native
highlighting.
Original comment by Eduard.Braun2
on 27 Nov 2014 at 12:48
Original comment by Eduard.Braun2
on 29 Nov 2014 at 5:20
Native highlighting is sometimes even lost when only scrolling in a page.
This was also reported as an AMO review:
'''"I've found that this extension interferes with the highlighting in the find
bar. To clarify: If you search for a word, then use the highlight function in
the find bar, the highlighting works until you scroll. Once you start scrolling
up and down the page, the highlight is gone. I've narrowed the problem to this
extension by process of elimination (i.e., disabling extensions one by one)."'''
Original comment by Eduard.Braun2
on 2 Feb 2015 at 9:10
The cause is a simple one: NodeHighlighter replaces text portions with document fragments containing those same text portions highlighted. This physically removes DOM nodes and adds new ones, and since highlights are technically just special text selections, removing the DOM nodes where these exist also removes the highlights (selections) themselves.
Simplest solution would of course be to just re-do the highlights after SearchWP did its thing.
I'm the developer of FindBar Tweak, and a user of both add-ons first reported this issue to me, which brought me here. Please let me know when you get back to developing the add-on and are interested in fixing this issue, as I would like to ensure compatibility between both add-ons. With the current SearchWP code, it's actually very hard to fix this just on FBT's side, especially since I see you've already committed changes that move the highlighting to the frame script, and I can't touch those from my add-on at all.
Hi Quicksaver,
thanks for feedback! Actually this is on the to-do list for next version and I planned to fix it exactly the way you suggest (disabling/re-enabling the native highlighting).
It's not ideal but I wasn't able to come up with a better solution that is compatible with SearchWPs current way of highlighting (modifying the DOM and replacing nodes) while being performant enough.
Regarding compatibility with FindBar Tweak: Let's continue in issue #105
It's not ideal but I wasn't able to come up with a better solution that is compatible with SearchWPs current way of highlighting (modifying the DOM and replacing nodes) while being performant enough.
Agreed, I came to the same conclusion when I checked SearchWP's code, which is why I didn't have any other alternative suggestions. When I work on https://github.com/Quicksaver/FindBar-Tweak/issues/76 (no idea when that will happen though), perhaps I'll be able to help with that. ;)
BTW apparently SearchWP removes Firefox's native highlighting not only when it adds its matches when changing the DOM tree, but also when it doesn't: https://github.com/legege/searchwp/blob/master/src/chrome/content/highlighter/highlighter.js#L59-L64
I guess this can be problematic for heavy dynamic/AJAX pages, that have constant onStateChange's (calling refresh() -> unhighlight() -> etc.). Thought I should mention it, as that means disabling SearchWP's markers through its toolbar button, or even clearing the search bar so it has nothing to mark, won't do much help to keep the native highlights.
Unless I misread something in SearchWP code of course.
No, you're completely right. ;-)
This is all on my to-do list and I hope to be able to fix it anytime soon, but it's gonna take some time since this part of SearchWP is a bit of a mess tight now and I'd like to clean it up in the process if possible.
Of course, I only mentioned it to make sure this was the case. :)
Original issue reported on code.google.com by
nap...@gmail.com
on 24 Nov 2014 at 8:04