Refined-github: Automatic redirects in empty profiles

Created on 16 Nov 2018  ·  15Comments  ·  Source: sindresorhus/refined-github

Visit an empty profile e.g. https://github.com/johannes-bucher from a random GitHub page. I'm "redirected" multiple times (probably history API) without interacting with the page. When I use the browser back button to try to get back to the initial page, I have to use the button multiple times.

bug good first issue help wanted

Most helpful comment

Oh, I thought that was what's happening, I didn't actually test it.

The URL changing when _loading more_ is rather awkward, with or without Refined GitHub, especially since the change happens with history.pushState instead of history.replaceState.

With a medium screen (900px tall) the button appears in my viewport anyway so even setting rootMargin: 0 won't change this behavior.

Ideally clicking on the "show more activity" button shouldn't change the URL, or it should at least use replaceState. cc @lukehefson (pushState is useful to enable the back button, but "go back" doesn't make sense on a "load more")

The most we can do probably is to minimize this annoyance by waiting for user to scroll first before loading more (only the profile page, the dashboard is fine the way it is).

I don't think we can prevent/undo this behavior, but perhaps someone knows a way.

All 15 comments

I've experienced this recently too, when I tried to debug this up, the culprit I found to be was infinite scroll feature from #1516.

The main reason being rootMargin at https://github.com/sindresorhus/refined-github/blob/483dc65817d3104e87cb0b0b4067bbb20a10eb7d/source/features/infinite-scroll.js#L31 is always less than 500px when the users timeline is empty, and keeps calling loadMore() which changes the URL.


/cc @dertieran

Hmm not to sure what to do here, this is basically how Github loads the profile activities. I don't think it really matters if the user activity is "empty", each time the .ajax-pagination-btn button is clicked the search gets changed. So to change this we would need to tamper with the history object or intervene and trigger the data load without the search change.

So I guess you could also reduce the rootMargin or limit the maximum btn.click(), but for me it is the intended behavior to load everything till it is out of view or it reaches the end.

but for me it is the intended behavior to load everything till it is out of view or it reaches the end

Yeah me too, but it is a little bit annoying at times.


So I guess there is nothing we could do here, or we could wait to see for any better ideas before jumping to conclusions.

rootMargin is what it should be. The problem is elsewhere:

The button gets clicked before GitHub attaches their click handler so the form gets submitted doing a full page reload. We had a similar issue on the homepage and there was some code to detect/avoid this behavior. I suppose it needs to be adjusted for the profile as well

The button gets clicked before GitHub attaches their click handler so the form gets submitted doing a full page reload

That may be another issue because I don't see any full page reloads, only "Show more activity" button is clicked.

@bfred-it What are you getting on empty profiles?

Oh, I thought that was what's happening, I didn't actually test it.

The URL changing when _loading more_ is rather awkward, with or without Refined GitHub, especially since the change happens with history.pushState instead of history.replaceState.

With a medium screen (900px tall) the button appears in my viewport anyway so even setting rootMargin: 0 won't change this behavior.

Ideally clicking on the "show more activity" button shouldn't change the URL, or it should at least use replaceState. cc @lukehefson (pushState is useful to enable the back button, but "go back" doesn't make sense on a "load more")

The most we can do probably is to minimize this annoyance by waiting for user to scroll first before loading more (only the profile page, the dashboard is fine the way it is).

I don't think we can prevent/undo this behavior, but perhaps someone knows a way.

How about this: _no more auto-load._

Instead of loading automatically from the start, it should start after the first "load more" click. The change shouldn't be terribly hard:

https://github.com/sindresorhus/refined-github/blob/master/source/features/infinite-scroll.js#L60

This line would become something like:

} else if (isUserProfile()) {
    form.addEventListener('submit', () => {
        observeEl('#js-contribution-activity', findButton);
    }, {once: true});
}

Instead of loading automatically from the start, it should start after the first "load more" click

That would be a little confusing, even for existing users. 🤷‍♂️


Starting autoload on scroll is still a reasonable option.

Pinging @lukehefson again about pushState (sorry if you are still on vacation).

Why confusing? That’s how a lot sensible of autoscroll work, even the docs here have a button at the bottom to “Autoscroll the rest of the site” (i.e. start auto scroll) https://infinite-scroll.com/

@bfred-it since I'm so used to it going automatically :grinning:

It either "auto loads" or "doesn't auto load", but combining them would cause a lot of confusion. I'm sure that David in the example shows a new and different way of handling auto loading on scroll.

But thinking from a general users perspective, and getting used to it auto loading automatically, changing it to "click once, scroll forever" does sound a bit weirder 🤷‍♀️.

But I might be wrong too, lets see what other thinks too.

The problem is that it can't go completely automatically because of the two pretty-annoying issues above. So we either hide it behind a clear action ("Click Load more once") or we drop the feature on profiles.

we drop the feature on profiles.

@bfred-it :arrow_up:

we drop the feature on profiles

Fair enough. Making the feature work on profiles is more work than any value it provides (until pushState is ditched).

PR welcome for review

Was this page helpful?
0 / 5 - 0 ratings

Related issues

yakov116 picture yakov116  ·  3Comments

sindresorhus picture sindresorhus  ·  3Comments

Celthi picture Celthi  ·  3Comments

Arcanemagus picture Arcanemagus  ·  3Comments

durka picture durka  ·  3Comments