search

Simon-Tesla / RaccoonyWebEx

A WebExtension that adds shiny features to art sites
MIT License
43 stars 4 forks source link

Add open tabs support for FurryNetwork #137

Open Simon-Tesla opened 2 years ago

Simon-Tesla commented 2 years ago

At some point FN replaced their infinite scroll with a paging mechanism, need to investigate if we can update the plugin to do proper "open all in tabs" support for it.

Eupeptic1 commented 2 years ago

From a really quick look, each thumbnail on the browse page links to the submission page with a consistent class - <a class="media-grid__item__link" [...]> - so it should be possible to key off of that. It appears to be the same class, whether you visit one of the "most recent" or "most popular" links, or do a search for a specific tag.

I probably won't be able to work on this in the next couple of days, but I might be able to do something with it later this week.

Eupeptic1 commented 2 years ago

tl;dr:

I added support for open-all-in-tabs to the FurryNetwork plugin. The revised plugin is on the furrynetwork-submission-id-and-open-tabs branch in my repo, here . If you click the "blame" button and scroll down to line 108, it's easier to see what I changed.

I ran tests of the revised plugin on Firefox, Chrome, and Edge, and all three browsers got the same answer.

Note: This change builds on the change already made in PR https://github.com/Simon-Tesla/RaccoonyWebEx/pull/121 , which closed https://github.com/Simon-Tesla/RaccoonyWebEx/issues/118 . That's why it's on the same branch I used for that change.

Long version

I modified the FurryNetwork plugin to have a working getPageLinkList().

It handles the various cases of page URLs on FurryNetwork that I learned about when fixing https://github.com/Simon-Tesla/RaccoonyWebEx/issues/118 .

Sorting not supported

The change does not support the idea of sorting or not sorting the list of tabs to open by submission date. It is set to never sort any list by date.

This is because FN tries pretty hard to redirect you one of their "most popular" gallery pages. The artwork on those pages won't necessarily be sorted by date, only by "promotes". If we sorted that list, the tabs would open in a different order than shown in the gallery, which I feel may be surprising to users.

If the user is on a "most recent" gallery page, the artwork - and the list of URLs we build - will already be sorted by date anyway.

It therefore won't try to sort the galleries on a user profile page by date, either, which is the same as most of the other plugins.

Community page

FurryNetwork's Community page has a gallery of user profiles that works exactly the same way as the artwork galleries. This means that the plugin can build a list of URLs from it, but it thinks the "submission ID" for each URL is the user's name, rather than an integer. This didn't seem to do anything bad to the rest of Raccoony when testing, but I figured I'd mention it.

No PR yet

I want to remove some of the logging before doing a PR. The plugin currently does three logging statements for each thing it's going to open as a new tab; if a user has set FurryNetwork to the maximum of 72 items per page, the ol' browser console gets kinda spammy.

Testing

Since this is a new feature, I did not try to test against a previous version of Raccoony. I decided instead to download the same set of submissions in different browsers, and compare. I realize this mostly only proves that the browsers all implement WebExtensions the same way, but I feel it's better than nothing. :D

I used the "most popular" (all-time) categories on FurryNetwork as test data, because they are unlikely to change much over time. This probably makes the test more repeatable in the future.

All tests were run on Debian Linux x86_64, desktop. Three configurations were used:

Firefox: 91.11.0esr, Debian 11.4 Chrome: 103.0.5060.134 (Official Build) (64-bit), Debian 10.12 Edge: 105.0.1321.0 (Official build) dev (64-bit), Debian 10.12

I did a smoke test in each configuration by trying to download one image from FN without using the new open-all-in-tabs functionality, and it worked.

I then tested the new functionality like this, for each of the three configurations:

Loop:

Repeat loop for Photos > Most Popular and Multimedia > Most Popular.

Compare the downloaded files across all three configurations.

Test results

All 3 configurations downloaded 74 files - 37 submission files (jpg, mp4, png, webm, gif, mp3) and 37 metadata files. This corresponds to a submission file and a metadata file for the 1 smoke test download, 12 artwork downloads, 12 photo downloads, and 12 multimedia downloads.

All 3 sets of files from each configuration compared binary equal with each other.

This shows that all three configurations are handling the new functionality the same way.

Eupeptic1 commented 2 years ago

I have updated the proposed change to remove the extra logging statements in getPageLinkList(). It is available here .

I tested the update in Firefox by using the open-in-tabs feature in each of the Artwork, Photos, Multimedia, and Community categories on FN, from either the the "Fresh" or "Most Popular Last Week" page for each category, with "Show" (items per page) set to either 12, 24, or 36. In each case, it opened the expected number of tabs, in the expected order.

I have noticed a couple of odd behaviors, which may be related to FN's single-page-app-ness, or how FN behaves in general.

  1. Come in from the beginning to a page like https://furrynetwork.com/artwork/fresh/ .
  2. The plugin runs, and the raccoon head offers just the Open all in tabs button, as expected.
  3. Click on any of the pieces of artwork on that page, to get the detail page for that artwork.
  4. The plugin runs, and the raccoon head offers the Download and Fullscreen buttons, as expected.
  5. The raccoon head also offers the Open all in tabs button, which is not expected.
  6. If you do click the Open all in tabs button, the images that were on the original gallery page (from step 1) open in tabs.
  7. Click the "Close X" at the top right of the artwork detail page, to return to the original gallery page.
  8. The plugin runs, and the raccoon head offers the Open all in tabs button, as expected.
  9. The raccoon head also offers the Fullscreen button, which is not expected.
  10. If you do click the Fullscreen button, nothing happens.

I think the plugin offers open-in-tabs on the detail page because FN shows the detail page as an overlay on the original gallery page; the gallery of thumbnails and links is still in the DOM and readable by the plugin. (Verified by looking for some of the other images in the inspector, while the detail page is up.)

I'm not quite sure why the plugin still offers the fullscreen button once you return to the gallery page.

If all of the above behaviors are considered acceptable within the current level of FN support, I will submit a PR for the plugin changes.

The plugin also still has the issue noted in #117 ; once you've pushed the Download button on FN, it sticks on Downloaded, even as you browse to other images.