Add scroll marker using fake scrollbar implementation - #436
Conversation
|
interesting! do you have screenshots? |
follow existing style.
Less noise.
- Can put "enable" or "disable" in description instead of messages. - Can omit "_enabled" from js code to shorten code lines.
pzhlkj6612
left a comment
There was a problem hiding this comment.
The code and L10N strings in this PR don't seem to be consistent with the existing style and design, and there are some useless if-else and try-catch statements.
I've modified your changes in arogl#1. PLease check. The code in "content/highlighter.js" needs more cleanup and I'm working on it.
You can directly merge that PR if it looks good to you. The merge commit can be preserved, and you don't need to force-push. The maintainer will squash all commits during PR merging.
I believe that keeping things consistent will help future developers. I also believe that we will compose some linter rules for this project then.
|
Thank you for merging the code. Now I'm continuing working on it. I think all markers in the virtual scrollbar should be added and removed simultaneously with the addition or removal of occurrences on the page, then the procedure will look more tidy and more integrated. |
|
Let me know when these changes are ready and I’ll have a final review 👍 |
|
Sorry forgot about this one. |
|
Thanks. I'm working on removing all |
"document.scrollingElement" has been widely used since 2016.
pzhlkj6612
left a comment
There was a problem hiding this comment.
Thanks. I'm working on removing all
try-catchblocks these days. The code in this PR looks to be against the existing code style.
I'm back and finished a mass PR. Please see arogl#2. Commit messages in it are also important.
Cleanup, reorganization, encapsulation.
I merged in and tested locally, it worked |
|
Let me know when this is ready for final review 👍 |
pzhlkj6612
left a comment
There was a problem hiding this comment.
Let me know when this is ready for final review 👍
Looks ready for final review! Let's move on and have this feature in the upcoming new version.
| for (let currIndex = 0; currIndex < len; currIndex++) { | ||
| charMap[charIndexMap[offset + currIndex]].ignorable = true; | ||
| } | ||
|
|
There was a problem hiding this comment.
Can you revert these whitespace changes? I don't like seeing code all bunched up like this, too difficult to follow.
There was a problem hiding this comment.
Can you revert these whitespace changes? I don't like seeing code all bunched up like this, too difficult to follow.
Addressed by arogl#3.
There was a problem hiding this comment.
Maybe @arogl is not familiar with or forget to read git-diff. It's very clear that we have some unneeded changes there: 2f047ec~1...bb8795a .
|
Changes look good to me, aside from the whitespace comment. I'll do a few tests locally, but should be able to merge soon. |
|
LGTM. Once the whitespace fixes are done, can you squash your changes? I'll merge once done. |
|
I'm cleaning unimportant changes in files such as manifest_firefox.json. |
JS: - We don't need to move the "charMap.length = count" line. - We don't need to remove those empty lines and affect readability a little bit? JSON: - Really, copy-paste is quick, but git-diff is a bit hard to read. - The EOF empty line is a pain for GitHub since the Web UI editor will always add that line. We should keep it.
pzhlkj6612
left a comment
There was a problem hiding this comment.
We're almost there!
In my view, there are still some minor flaws in this code. The comments below are for good changes, while my suggestions are in the PR: arogl#3
| } | ||
| } | ||
|
|
||
| // Collect occurrence IDs from highlight spans |
There was a problem hiding this comment.
nice clean. that was a leftover.
| if (options && options.scroll_markers) { | ||
| scrollbarMaker.setActive(index); | ||
| if (options.scroll_markers) { | ||
| Find.Content.ScrollbarHighlightMaker.setActive(index); |
There was a problem hiding this comment.
Nice removal of the undefined check with options since we have already checked it above.
Maybe we can keep the history in this PR? When merging PR, you're able to choose "squash and merge", and then all of our reviews and comments are still meaningful and the "develop" branch should have only one commit. Force-pushing is not recommended, at least in my opinion. Docs: Merging a pull request - GitHub Docs | https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request#merging-a-pull-request . |
Restore unneeded changes from JS and JSON files
| /** | ||
| * Initialize the component with the given search options, discarding | ||
| * any previously mounted overlay. Must be called before mount(). | ||
| * | ||
| * @private | ||
| * @param {object} newOptions - The search and highlight options | ||
| * */ | ||
| self.init = function (newOptions) { | ||
| self.destroy(); | ||
| options = newOptions; | ||
| occTopPositionMap = new Map(); | ||
| }; |
There was a problem hiding this comment.
| /** | |
| * Initialize the component with the given search options, discarding | |
| * any previously mounted overlay. Must be called before mount(). | |
| * | |
| * @private | |
| * @param {object} newOptions - The search and highlight options | |
| * */ | |
| self.init = function (newOptions) { | |
| self.destroy(); | |
| options = newOptions; | |
| occTopPositionMap = new Map(); | |
| }; | |
| /** | |
| * Initialize the component with the given search options, Must be | |
| * called before mount(). | |
| * | |
| * @private | |
| * @param {object} newOptions - The search and highlight options | |
| * */ | |
| self.init = function (newOptions) { | |
| options = newOptions; | |
| occTopPositionMap = new Map(); | |
| }; |
We already have a Find.Content.ScrollbarHighlightMaker.destroy() call in "self.restore()" of "content/highlighter.js", so any leftover will be cleaned up. So, we can safely remove it from here.
There was a problem hiding this comment.
So, we can safely remove it from here.
So, we can safely remove the self.destroy() call from here.
There was a problem hiding this comment.
Comments should be updated, too.
I don't know if the suggested changes above are readable on your web browser? GitHub's UI is glitch sometime, so you may need to refresh it multiple times.
| if (overlay && overlay.parentNode) { | ||
| overlay.parentNode.removeChild(overlay); | ||
| } | ||
| if (globalStyle && globalStyle.parentNode) { | ||
| globalStyle.parentNode.removeChild(globalStyle); | ||
| } |
There was a problem hiding this comment.
Maybe we can apply lint rules in the future for using the convenient "Optional chaining" stuff? I dunno. I prefer optional chaining. Now let's don't change it and keep the style consistent with other code lines. Here I'm just making notes.
| #find-ext-scroll-marker-container { | ||
| position: absolute; | ||
| top: 0; | ||
| left: 0; | ||
| right: 0; | ||
| height: 100%; | ||
| } |
There was a problem hiding this comment.
Mouse can't drag and drop the thumb, unless we do this:
| #find-ext-scroll-marker-container { | |
| position: absolute; | |
| top: 0; | |
| left: 0; | |
| right: 0; | |
| height: 100%; | |
| } | |
| #find-ext-scroll-marker-container { | |
| position: absolute; | |
| top: 0; | |
| left: 0; | |
| right: 0; | |
| height: 100%; | |
| pointer-events: none; | |
| } |
(Then the same declaration for each marker in .find-ext-scroll-marker {...} can be removed.)
Embarrassingly, my previous implementation didn't care about the style of the marker container, and then the mouse could normally interact with the thumb. Bug was hidden.
HOWEVER, since we don't have any overflow related things applied to the container, a zero-pixel-width and zero-pixel-height DIV does not hurt anything. Directly remove this rule from here and the corresponding class naming thing from "scrollbar.js" looks simpler and more acceptable to me.
| #find-ext-scroll-marker-container { | |
| position: absolute; | |
| top: 0; | |
| left: 0; | |
| right: 0; | |
| height: 100%; | |
| } |
What do you thing?
There was a problem hiding this comment.
06be275: directly removing the marker container is not a bad idea but looks like my intent about using that container didn't express clearly. Let me explain more:
- No
track.querySelectorAll(...), but a simplemarkerContainer.children. The code will be more understandable to future developers including all of us a month from now. - Managing common properties is simple. For example, the
pointer-events: none;declaration. - Better dev experience: in Developer Tools, we can collapse all makers into one parent element and see a clear view, like this:

Thus, if you're going to inspect something other than markers, for example the thumb, then those markers won't bother you.
That's it. I really recommend you use a container.
pzhlkj6612
left a comment
There was a problem hiding this comment.
It works. Now let's wait for @brandon1024 to test this PR.



Fixes
#368
Changes Proposed in this Pull Request:
Additional Comments and Documentation:
Produced with the help of claude