Delaying Page With A Password Prompt Instead Of A Countdown

[CashMoneyKwam]

Disclaimer: It's entirely possible I'm misunderstanding the options, so I asked in the General/Q&A discussion area, unless this feature isn't available, in which case I would have to request for it in the Ideas area. I looked around to see if I could find any similar threads and tried to find a solution on my own, but I couldn't. If I missed any, I sincerely apologize. 

The problem: I want to be able to bypass the blocked sites by using a password in the same tab that redirects when entered correctly. I included a rudimentary photo edit of what I'm imagining, which is essentially what the override screen looks like. 

My current configuration: Manually opening the extension options to override and clicking on the hyperlinks of the default LeechBlock redirection page. I would prefer entering the password on the blocking page itself instead of having to override every time I need to bypass. 

Current.Configuration.mp4

A solution that didn't work: I tried changing the redirected page to the override url in the options, thinking that this could achieve what I wanted, but since this is already a redirection, it wouldn't redirect again to the original site. Clicking the "Ok" button just closes the tab. The url I used was chrome-extension://blaaajhemilngeeffpbfkdjjoefldkok/override.html

Redirect.To.Temporary.Override.In.Options.mp4

Conclusion: I'm not sure if what I'm imagining would interfere with the way that LeechBlock currently functions, but this is an option I really want in an otherwise perfect extension. It may seem small, but it affects my productivity workflow, so I really want to correct it. I would appreciate it if anyone would help me, if I am indeed misunderstanding the options, as there are some other website blockers that work like what I'm imagining but fall short in many other areas. If the concern is that this goes against the purpose of using Leechblock, I'm not advocating for it to be mandatory, just an additional option/alternative, so the user isn't stuck with one way or the other. 

Browser: Google Chrome

Release Version: 1.6.3

My LeechBlock Options.txt file: 

LeechBlockOptions.txt

[proginosko]

If I understand this, what you're really looking for is a version of the delaying page, but with a password prompt rather than a countdown. Correct?

[CashMoneyKwam]

Yes, a delaying page with a password prompt instead of a countdown would work spendidly for my needs. I had used the delaying page feature many times in the past but obviously with the aforementioned countdown, I still needed to actually block the websites, not just delay them. Also, the delaying page feature is able to affect individual pages in contrast to the override feature, which forces the override to being universal. This is exactly what I want, where I can enter a password within the same individual tab that will redirect me, without having the need to universally override everything.

May you please implement a feature like that? I would include another photo edit, but it would be virtually the same as what I provided earlier. Thanks for being so understanding.

[proginosko]

Please post this as a feature request/suggestion in the Ideas category so that other users can upvote it.

[CashMoneyKwam]

Happy New Years! I've switched the category to the Ideas category a while back and it hasn't really gotten an upvote, but I don't think it's necessarily the idea's fault. Do you have any plans on implementing a delaying page with a password prompt instead of a countdown in an upcoming patch? I've made sure to wait patiently for other people to contribute to the discussion, but it seems this idea hasn't gotten enough visibility. I also read the other ideas and the patch notes to see if it's already been implemented, but I didn't see it. If I missed anything, I apologize.

[proginosko]

I think this is a good idea, and I plan to implement it when I get the time.

[GrocerPublishAgent]

I was thinking about this from wanting my own custom delaying page from a file URL. I thought it would be nice to have a function on the window in the MAIN world that my custom delaying page can call to "finish" the delay.

My understanding is the delaying page sends a message to the background script when the delay has elapsed.

                // Notify extension that delay countdown has completed
		let message = {
			type: "delayed",
			blockedURL: countdown.blockedURL,
			blockedSet: countdown.blockedSet
		};
		browser.runtime.sendMessage(message);

A naive approach is to send the same information using window.postMessage to a listener inside the content script.
https://github.com/proginosko/LeechBlockNG/blob/master/content.js

window.addEventListener('message', function(event) {
  // Security check - only accept messages from the page we're injected into
  if (event.source !== window) return;
  
  // Check if it's a message meant for our extension
  if (event.data.type === 'REPORT_DELAY_TO_LEECHBLOCK_NG') {
    if 
    if (typeof event.data.blockURL !== "string) return
    if (typeof event.data.blockedSet !== "number") return
    browser.runtime.sendMessage({
        type: "delayed",
	blockedURL: event.data.blockedURL,
	blockedSet: event.data.blockedSet);
	source: window.location.href
  }
});

For security the background script could check the source matches the configured blockURL.

Concretely this would let me create my own delaying page. For example file:///Users/user/.local/bin/squat-reminder.html Which reminds me to get up and do a short body weight exercise, and then when I'm done, I can click a button to continue to the original website.

[proginosko]

Yes, via the content script would be the way to support custom blocking/delaying pages. The trick is to keep the code minimal, since the content script gets injected into every webpage, and we don't want to incur a general performance cost. But it's something I plan to work on.

In the meantime, I'm working on a password prompt version of the blocking page.

[GrocerPublishAgent]

I thought about this problem some more today and came up with this decision tree:

1. Can we add scripting permission? If yes, we can inject the API code only into delaying pages.
2. If no, we either:

• Add a special path segment to identify delaying pages
• Modify the built-in delaying page to optionally show an iframe delayed.html?$S&$U&iframe=file:///my-example-custom-delay-page.html
• Or measure the performance impact of injecting the code everywhere

---

Our first decision point is: Are we willing to add the scripting permission? This permission would let us dynamically inject our delay API code only when needed, specifically when we redirect to a blocking page. This is the cleanest solution. Zero performance impact on regular pages, and the API only exists where it's needed.

If we can't add the scripting permission, I think we are stuck with static content script declarations. This means any code we want to run in the delaying page must be declared in the manifest at build time. We can't dynamically inject code based on runtime conditions.

The natural question is can we identify delaying pages? One idea is to require delaying pages that want to use this API to have a specific URL structure that is very very unlikely to exist on the internet. This would let us declare a separate content script in the manifest that only runs on pages with that path. The background script would need to construct the blocking page URL with this path segment. This is a bit hacky but would work without new permissions. The random base64 at the end of the path would be hardcoded for every user of the extension. I generated an example value with openssl rand -base64 16. The idea is to eliminate natural collisions.

{
  "matches": ["*://*/*inject-leechblock-delaying-page-api-F9OTkexns4xAhx7uTQge_Q/*"],
  "js": ["expose-api.js"],
  "run_at": "document_start"
}

If the path-based approach is not acceptable, we could modify the built-in delaying to add support for an iframe query parameter. The delaying page would check for this parameter and, if present, display the specified URL in an iframe (either fullscreen or with a border). I would modify blocked.js to inject the iframe element only if the query parameter is present and setup listeners for postMessage on the child iframe. Sandbox attributes on that iframe would provide reasonable security.

• The user configures the custom block URL in the Leechblock settings delayed.html?$S&$U&iframe=file:///my-example-custom-delay-page.html
• The delaying page checks for an iframe URL parameter
• If found and the URL parses correctly, it displays that URL in an iframe
• The parent delaying page retains access to the browser runtime API since it's still on the extension URL
• The custom content loads in the iframe, and uses postMessage to request actions from the code running in the more privileged extension page context.

Optional enhancements for future versions: Additional query param to control iframe display (fullscreen vs inset into existing delay UI). This approach seems like it could provide the customization benefits while keeping the implementation relatively straightforward. What do you think?

If none of these ideas are acceptable, we're left with injecting the code into every page. This brings up the question of performance impact. I understand your concern about the performance cost of injecting code into every page, but I don't know at the moment how to measure this impact or what would be considered acceptable.

I'm willing to conduct the measurement, but I want to check if you have a measurement technique first. My naive thought would be to:

1. look for some browser API that reports the script parse and execution time on page load.
2. Create a test harness that injects varying amounts of content script code
3. Measure the difference in load times between versions
4. Run multiple tests to get statistically significant results

[proginosko]

Version 1.7 (uploaded and under review for Firefox & Chrome) adds a blocking page with password access (per the original request) as well as support for custom blocking/delaying/password pages.

Documentation for the latter will be posted on the website later, but for now it's enough to know that LB will insert the content script blocked.js into any webpage with lb-custom in the URL path, and the URL for the blocking page must end with ?$S&$U (to pass the block set number and the URL of the blocked page).

Example pages:

• https://www.proginosko.com/lb-custom/blocked.html
• https://www.proginosko.com/lb-custom/delayed.html
• https://www.proginosko.com/lb-custom/password.html