• Chrome extension to make the whitespace in subforums not clickable
    24 replies, posted
If you're from the old forum you might've noticed that now clicking anywhere on the row for a thread will take you to the thread, as opposed to only being able to click on the title. Hell, even if you never used the original site you probably thought that was a stupid idea, and you're right. So I made an extension to make it work like it did on oldpunch, where clicking on the thread title will take you to the first page of a thread, clicking on the "Unread" tag will take you to the first post you haven't seen in the thread (where you're directed to by default currently), and clicking on whitespace will do nothing, as clicking on whitespace should do. It also applies a similar change to the separate subforum links on the homepage, so the whitespace there will also not act as a link. However I added an option to disable that part, as I almost never go back to the homepage and never noticed that being a problem; I only included it for consistency. You can right-click on the FP logo icon next to your address bar and select "Disable Subforum Fix" to disable it. If the FP logo doesn't appear next to your address bar, click on the three dots in the top right corner and it should show up at the top of that menu. If you notice any bugs, or something breaks down the line (which it very well might as the site is still being worked on a lot afaik), just post here about it or message me if that gets added. It doesn't use any CSS so it shouldn't conflict with most custom CSS, but it does remove and manipulate some DOM elements so if you do notice a conflict let me know. FP Menu Fixer
Any reason it needs to be able to read my browser history?
Uh, no, and it doesn't. I dont' know what permission makes it say that. This is the manifest: {   "manifest_version": 2,   "name": "FP Menu Fixer",   "version": "0.1",   "background": {     "scripts": ["background.js"]   },   "content_scripts": [     {       "matches": [         "https://forum.facepunch.com/*"       ],       "js": ["content.js"]     }   ],   "icons":   {     "128": "icon.png",     "64": "icon.png",     "32": "icon.png",     "16": "icon.png"   },   "browser_action": {     "default_icon": "icon.png"   },   "permissions": [     "activeTab",     "tabs",     "contextMenus",     "https://forum.facepunch.com/"   ] } If anyone knows what in there makes it say it can access your history, I'll remove it and update the extension.
The "tabs" permission triggers the browsing history flag. Not sure why you need access to every single tab to begin with, but that's what's causing it nonetheless.
The way I'm doing it, if I don't have permission for the tabs and you open an FP link in a new tab, it will trigger the code but the JS will be injected in the current tab. There might be a better way to get it to inject JS in the correct tab but I made a system to do it a while ago and I've just been copy/pasting it into new extensions. Also there's a github link in the OP now, didn't want to connect this to my personal github and didn't want to bother to make a new account, but I can see why people would be wary of that permissions warning, so it's up there now.
Shouldn't have to have it running on the background, that's what content_scripts are for is it not you've already set the matches, but the file you point it to does literally nothing
I'm not sure what you mean, but the gist is I need access to the tabs, which has to be done in the background script as far as I'm aware. The content script does very little, yes, but it does notify the background script when a page has loaded, and then the background script sends a JS script as a string to be executed in the correct tab. I'm sure there are better ways to do it, but I wrote this for myself using stuff I'd already done as a skeleton and just changing the string that's passed to be executed as Javascript. The original project I'm copying from had good reason to make heavy use of both the content and background scripts, this one not as much, but it works.
The stesmdb extension which I generally refer to does not even use background scripts at all
Thank you, you were pretty much right. I stopped being so goddamn lazy and now I understand message passing much better. Most everything is now done in the content script but the background is still used to keep track of the variable that determines whether or not to apply the subforum fix, as the user can toggle that on/off. And as a bonus, permissions now only asks for contextMenus and forum.facepunch.com, so it shouldn't be asking users for access to their entire browsing history anymore. I've published an edit and Github has been updated with the changes, google will push them out to the store/anyone who's downloaded it... whenever it's ready, I guess.
This should be possible with custom CSS, I got it 80% working. Will see if I can get it working completely tomorrow.
The sensible way to disable it really is just disable the addon, because you won't actually find people needing a fast way to disable it, because why would you disable a fix to make the forum a lot more functional. People who don't need it wouldn't have downloaded the addon to begin with
No, sorry, it disables only part of the functionality. It will always apply itself to threads in a subforum, but there's an option to have it not apply itself to the links to subforums when you're looking at the homepage.
I wonder if you could add another thing that is slightly related to this. https://i.imgur.com/GjTK2RW.png The link on the front page of a thread used to go to the last unread message. Now it always goes to page one. I now always have to go to the subforum in order to get to the actual last read message. In oldPunch there was actually a separate button on the frontpage that got you to the first page. Or it was vice versa, either way you had both options. Personally I just want the thread shown go to the last read post, so I can avoid having to go in the subforum first.
this should just be a rewrite replacing /1 with #unseen
Unfortunately lordcrypto is right, to go to last unread you need to know the page number that the user was last on, and that information isn't available from the home page. There might be a way to do it though, I'm going to look into it in a bit.
The extension should now do this. As the description page now details, it does need to keep track of the threads you've viewed to do this. Since it is now keeping it's own record of threads you've viewed, when, and what page, I've also added the option to disable that completely from the extension's icon menu. Trust me, it's not doing anything malicious, and I as the extension creator have no access to this information anyway, but I understand if someone isn't comfortable with that. Disabling this will also immediately erase any data it's already saved as well as stopping it from collecting any more. An explanation of why it does this is on the store page's description, and the code has been updated on github if you want to see exactly what it's doing.
Did it break? Seems like I can click on whitespace again and it doesn't remember the last visited thread on the front page.
Oh yeah sorry, when 1.3 went out I had to essentially wipe all existing viewed threads. I noticed that the part of the url that spells out the name of the thread isn't actually necessary. For example, https://forum.facepunch.com/f/general/bcrdj/LMAO-Pics-V-How-have-we-gone-30-minutes-without-this-thread-being-recreated/1/ and https://forum.facepunch.com/f/general/bcrdj/1/ both go to the same place. Clicking on your alerts in the top right takes you to the thread without the title in the URL. This was causing each thread to be entered as two different threads if you visited through a subforum and then through your alerts button. So now it always leaves off the title, even if the url includes it, when determining if you've visited a thread before, and the old format for stored threads doesn't match what it's looking for. This shouldn't happen again in any future update, unless the forum navigation structure is changed.
@Laharlsblade Did something break with Garry's latest updates? Seems like threads shown on the front page don't direct me to latest read anymore but to page 1 again.
Probably, I'll look into it, thanks. There's gonna be one big update soon and the fix will unfortunately have to come with that because my local version is heavily modified and not user ready and I'm too lazy to get the live version from github and fix it there
Thanks for looking into it. I already catch myself wanting to shoot myself having to go to a subforum first to get to the last read post when I see it on the front page... I still don't get why that goes to page one.
Huh, it's still working on my end, even when I use the live version. Can you open a tab, press Ctrl+Shift+I (or Ctrl+Shift+k on Firefox), then go to the homepage and copy/paste or take a picture of what shows up in the console? Also just to be sure, you're only talking about the links on the right side of the page where there's one per subforum, not the ones on the left under "Latest Threads," right?
For some reason it is back working again. I swear it drove me mad that I always got put to page 1 of LMAO for example when I clicked it on the front page. And yea I was talking about these on the frontpage. https://i.imgur.com/PDGjIdY.png Will report again if something is off.
@Laharlsblade It happened again: https://i.imgur.com/wTEkDmy.png Error on the right is from the extension.
Alright, I do know why that's happening then. Some url for one of the threads doesn't match the regular expression I was using to get the thread and forum IDs from the url. Because I just assumed no URL would be fucked up enough to evade the regex completely I didn't add any error checking and so the loop ends early, as soon as that error occurs, and before it's able to replace all the subsequent links on the page. This will only happen when one of those fucked up URLs is on the homepage, so that'd be why you're only noticing it sometimes. I've added a fix locally so this shouldn't happen after the update, sorry.
Sorry, you need to Log In to post a reply to this thread.