nexushoratio / userscripts Goto Github PK

Bringing up the help screen immediately shows the scrollbar, but then it fades away after a second or so. If the user misses it (I did!) there is no indication there is more content to see.

Need to figure out how to make it sticky in this case.

The recent support for J and K, where it both hides the current post (well, technically, toggles) and then navigates to the next post has a small problem.

The toggle part is async, and when that process finishes, the [Undo] button the old div gets focus and the new selected posts moves down a few pixels.

Not sure how to best handle this.

We could wait until the toggle action has finished and then navigate. But if there is a network issue, that could wait forever. Or we could detect the change to focus and go back to the new post, though I suspect that would still cause jitter, but at least it would end up where we want it. Either solution would need to somehow detect that the operation has finished.

We do have the VM.observe stuff handy, so maybe it could be used here. Perhaps just catch the mutation then refocus on current.

I'm finding it cumbersome to use j and k to move up and down and then use x to mark the message read (aka, hiding it). So I think uppercase variants that do both makes sense.

While trying to implement v p, I spent a lot of time trying to figure out how to make it work with the built in app routing, but I simply couldn't figure it out.

Sit on it for a while and maybe revisit it later with a clear mind and some more experience.

User cannot actually activate one of the offered reactions. Only regular liking works.

I wonder if a click handler or something is interfering.

As it is getting bigger, even I am forgetting what keys do what. Going to need a help screen.

Over in #6 , I suggested that we have a different kbService per view. It would make sense to make use of this in building the help screens, and either only show those relevant to the current page, show that set first, or navigate to that #fragment.

Looking at another userscript, LinkedIn Enhancer, it uses jQuery plugin called SimpleModal.

I wonder if this kind of feature could be added to VM.shortcut or not.

Anyway, simple API could replace the current kbService.register() calls with something like:

kbs.register(view /* navbar */, keys /* g h */, section /* Jumping */, description /* Go to home page */, func /* goHome */);

That would both register with the appropriate kbService and populate the help menu.

If it is not obvious, I stole the idea of g h keys, Jumping and so forth from GMail's keyboard nav.

Just noticed that when loading posts when the New Posts button is visible uses the old technique of setting an array index to 0.

Currently only supports /feed posts. What else can be done?

/jobs/search is the most likely next candidate.

Have a keystroke to activate the ... see more link.

GMail uses o and TheOldReader (and so I'm guessing Google Reader) uses x for this.

The LI UI only supports expanding, but not collapsing. So bonus if can be a toggle.

Reference https://gomakethings.com/nodelists-vs-arrays/ et al.

NodeLists (as returned by querySelectorAll) are a language agnostic DOM thing. For example, in the Python DOM API, there are also NodeLists which are not Python lists, though, similar to JS, they do support some Python sequence things.

Anyway, might as well just put Array.from() around all querySelectorAll calls and remove the current use of Array.prototype.findIndex.call.

Actually, most uses of findIndex can probably be replaced by indexOf as they are just matching elements.

I'm learning things!

By default, using the scrollIntoView() API will position the post to the top of the viewport. Which means the first bit of the post (the user, menu, etc) are hidden under the fixed navbar. In searching, it appears the way to deal with this is to use the scroll-margin-top css property.

Ideally it would be assigned to a specific element which is the scroll container. But I couldn't figure out which one that is. So to start with, just using an overly broad css rule of div { scroll-margin-top: VALUEpx }. Should make that selector a bit more precise.

Menu buttons are styled as (⋯) where as the New Posts one is actually in a button element.

However, the button element is enabled, thus tabbable. Changing the menu buttons to real buttons elements make them that way as well. Which, while cute, doesn't really fit things.

I tried adding disabled to them, but then they look bad. Setting tabindex=-1 helps with tabbing, but the first one on the help page always starts out focused, no matter what, again, spoiling the look.

So will require learning some more CSS or HTML or something.

If the user goes to do a search, then tabs away, the focus will be up in the global nav bar. Nav functions will still work, but the focus stays in the nav bar.

A user might expect that the focus be on the post (and it used to, until issue #9 was fixed). But now we have no easy way for the user to get in post elements.

Well, they can explicitly click on the post, but since the whole point of this exercise is to reduce mouse usage, there should probably be a better way.

Likely f for focus.

If the window is narrow enough, the LinkedIn News <aside> shows up under all of the posts and there is a See new posts button instead or auto loading. Should handle that case.

A common pattern I'm seeing is something like

this._focusedElement.querySelector('complicated[CSS=selector]').click();

And sometimes:

let el = this._focusedElement.querySelector('selector1');
if (el) {
  el.click();
} else {
  el = this._focusedElement.querySelector('selector2').parentElement;
  el.click();
}

Maybe something like:

tryClick(this._focusedElement, ['selector1', 'selector2']);

That doesn't help with the parentElement situation (at least not until FF supports .has()), but it might simplify the common case.

Loading more comments causes the click handler to refocus on the post, losing which comment was in focus.

https://github.com/violentmonkey/vm-url

Support for SPA. Might be able to replace our existing VM.observe and initial pages.activate call.

Hot keys are still enabled when the help screen is up. Which seems like a bad idea.

If focus is on the last comment, n should go back to the top (likely the post itself).
If focus is on the post, p should go to the last comment.

LI does not load all comments. Sometimes there are some skipped and replaced with Load previous replies button.

Maybe have l be context sensitive and find the next one and click it.

One thing I'm really noticing with notifications is, when the user goes back to the notification view after activating a notification, all state is lost.

A simple refocus to the current notification doesn't work because the page is reloading all of the notifications and it hasn't finished yet when the class is reactivated. So nothing to do!

Not unlike what happens when the site initially loads and we need to calculate the navbar height.

Also, similar to the issue we have with jitter on post toggle (#17).

For reactivation, we're already doing some observation on the page in _enableClickHandler(). Maybe we can do something useful with that.

Oh, hey, notifications can have a Show more results button!

Not sure on an easy selector.

The LI UI has a new X button that hides a post.

I'm not sure what the difference between clicking that and using the meatball menu -> I don't want to see this -> It's something else. It definitely seems to call a different API to the backend.

Upon reload, it seems that posts marked using this new X button are back. But then, also so are those marked with [something else].

May want something more drastic than LI's experience. For example, if hiding a post, completely remove the element by marking it hidden or something

We could have multiple dialogs, and have the ? cycle through them. One each for Help, Feedback, Configuration (if we ever need it). Or have proper tabs or something.

I'd prefer not to bring in something like jQuery.

https://github.com/violentmonkey/vm-ui

See if it would be helpful in replacing the current <dialog> method we use. Particularly in light of the stretch goal in #39. Pondering a tabbed UI there.

Currently we add a tabindex attribute to the message <div> then call el.focus().

While this does result in a nice blue outline around the post, it appears that randomly adding tabindex is an accessibility issue. See https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex#accessibility_concerns

Originally I tried to find the first item that could be focused inside the <div>. However, that kept ending up being the meatball menu instead of the author, which is really next in the tab order.

And even then, the post author only gets focus first when it is a primary post. For like/comment/repost activities, the tab order is user-pic, user-name, meatball, X, original-author. Not sure what looks good in those cases.

<g><h>ome
<g><m>y network
<g><j>obs
<g><n>otifications
<g><p>rofile

The navbar buttons do not have IDs, so would be slightly more complicated than getElementById('foo').click(). Might be easier to simply navigate to the appropriate page using location.assign() or similar. Need to see what the internal stuff uses.

On the other hand, maybe querySelector('#global-nav [magic to match the string Home]').click() wouldn't be so hard.

This is related to how isInput and VM.shortcut conditions work.

Right now we track focus and blur event to detect when keys should be disabled (for instance, when typing into a text field). However, when a focused element is removed (as what happens when closing a message popup), no blur event is sent. This is documented

Note however that blur is not fired when a focused element is removed from the document.

With no blur event, the current code does not detect this situation, and the keys stay disabled.

After turning on every notification type, I now have a very full notification page, including some that fail to trigger.

Will just use this as a catch-all bug for all I currently have.

This is what GitHub does.

Currently hard coded to 76px. Should probably use el.clientHeight instead.

If the window is narrow enough, the navbar will reduce the search field to a button, which will then expose the search field.

But if it is hidden, the / will not work.

The css classes seem to be named *-show-more-text and there seem to be at least three different ones. One for regular posts (2 lines), one for posts engaged by friends (5 lines), and one for groups (3 lines).

These are controlled by the attribute max-height with a value of n*2 rem, where n is the number of lines desired for that type.

Setting the value to a high number doesn't actually remove the ...see more button, at least not with my minimal experimentation.

Likely use the l key.

This may be tricky for at least a couple of reasons.

First, making sure we properly differentiate between liking a post and liking a comment.

Second, ability to bring up the like menu (where like/celebrate/support/etc live). The up-arrow button doesn't show up until the like button gets focus, or on mouse events.

Maybe start with giving focus and letting user TAB SPACE SELECT the appropriate item. Better might be combos like 'l l' for like, 'l c' for celebrate, 'l v' for love, etc. But as this submenu is ephemeral, may be hard to find and click.

Following up on another issue, I think it makes sense to consider hiding a message as an active engagement rather than passive, so should be uppercase.

Just like we do for posts in the feed.

While doing work on navigation looping, I'm finding myself wanting to directly jump to the first/last post.

Like looping, it makes sense to do this for any place we scroll. Posts, comments. notifications.

Likely Home/End.

Add ability to navigate through comments. Maybe n and p and also perhaps C and L. Though the latter will require figuring out what the current context is (focused element is a comment rather than a post).

If the user tabs away to another post, or manually scrolls and clicks in one, we currently do now know about it.

Before handling the keystroke, we should check to see if the current focused element is still in the same post, and if not, then figure out which one it is in, and update our global variable to match.

Probably at least need @supportURL and @downloadURL.

While writing the notification code, where different types of notifications need different support, I won't be able to catch them all.

Right now we just pop up an alert saying to file a bug. But no details on how to do that (and can't do much in the alert anyway).

Stretch goal: Stow away the recent failure and have the help screen be able to retrieve it so the user can review it and maybe include it in a bug report.

'/' should go to search window. Probably #global-nav-search

• Test with TM on FF
• Test in base Chrome on Chromebook
• Test with at least one manager on Chrome on Chromebook

Need a keystroke to read comments. Maybe c, and reserve C for making a comment.

Maybe a policy of lowercase letters for passive engagement (like navigating) and uppercase for active engagement (like Posting or Commenting).

While in a chat textarea or the search input field (or whatever they are), they nav keystrokes are still active. Which makes writing text that contains j or k right now difficult.

The meatball menu (the three horizontal dots, ⋯) hides other action buttons (e.g., Save post). Unfortunately, I don't think I can activate those other button don't exist until the meatball menu is open. DHTML FTW.

Maybe I could do something fancy like click the menu, detect when it has fully rendered, then click one of the other buttons. But it feels really fragile.

Somewhere on a given post, there is a way to click on it and open it up by itself. Sometimes I click it by accident, but I can never do it on purpose.

I can force the issue with meatball menu -> copy link to post -> view post. And that goes to /posts/....

Also, one can more easily click on the original poster (person or company), the influencer, the group, etc.

While a post has focus, it should be possible to do all of those with keys. Possible v for visit (or view).

• v p view post
• v g view group
• v r view reactions
• v P view Poster
• v i view influencer (this could get tricky as a liked repost will have OP, reposter, influencer)

At the top of the feed, there is "Start a post", "Photo", "Video", "Event", "Write article".

Most of those are easy to find buttons. But what keys? s-* for share? C-* for create? Then what, since both post and photo start with p? P for post (since that is likely to happen most often), then multikeys for the others? Or maybe just a hotkey to get to that area and let the user TAB around?

It only pops up every so often, and goes away on a page reload. So this may be fun.

Looks like just up down and delete.