Open Simon-Tesla opened 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.
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.
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 .
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.
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.
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.
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:
~/Downloads/raccoony/furrynetwork
Loop:
~Downloads/raccoony/furrynetwork
asideRepeat loop for Photos > Most Popular and Multimedia > Most Popular.
Compare the downloaded files across all three configurations.
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.
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.
Open all in tabs
button, as expected.Download
and Fullscreen
buttons, as expected.Open all in tabs
button, which is not expected.Open all in tabs
button, the images that were on the original gallery page (from step 1) open in tabs.Open all in tabs
button, as expected.Fullscreen
button, which is not expected.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.
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.