Can't access Browser Page via popup's `Open Extension Page` button

[ar-rm]

Overview:

I've been unable to access the Browser Page for a few months.

Userscripts: 4.4.5 (82)
Safari: 16.5

Steps:

• Click the Userscripts icon in the Safari toolbar
• Click Open Extension Page

Result:

• Nothing
• No errors in the Safari console, Console.app, etc.

Other info:

• All of my user scripts seems to be working as expected.
• I tried running Inspect Element via the toolbar Popup menu. But it dismisses as soon as I try to interact with the Userscript popup.
• I tired Develop > Web Extension Background Content > Userscripts. But again, no errors.
• I've searched through the issues here and don't think I found anything similar. Apologies if I missed something.

---

I've been treating this mostly as an inconvenience, since I can edited my user scripts directly via their .js files in ~/Library/Containers/Userscripts/Data/Documents/scripts

But it does mean that I can't get to the Settings modal.

Questions:

• Is there an alternate way I can reach the Browser Page?
  • Maybe directly via a URL?
• What other steps could I take to help out the developers?

Thanks!

[quoid]

I am wondering if you would see an error in the background page if the openExtensionPage function failed from the popup...

You could try to open the browser dev tools for the popup by right clicking anywhere in the popup and selecting Inspect Element. From there you'd want to click Open Extension Page in the popup and see if any errors get logged, but I think doing that might close the popup. Alternatively, once the dev tools open and you navigate to the console, you could run document.querySelector(".link").click() and see if anything gets logged.

I don't have a Safari browser that old running on my machine.

Also, what OS version are you on?

[ACTCD]

This is strange because the code for the button is fairly simple:

userscripts/src/shared/utils.js

Lines 180 to 192 in 4de92f7

	export const extensionPaths = {
	page: "/dist/entry-page.html",
	popup: "/dist/entry-popup.html"
	};
	export async function openExtensionPage() {
	const url = browser.runtime.getURL(extensionPaths.page);
	const tabs = await browser.tabs.query({url});
	const tab = tabs.find(e => e.url.startsWith(url));
	if (!tab) return browser.tabs.create({url});
	browser.tabs.update(tab.id, {active: true});
	browser.windows.update(tab.windowId, {focused: true});
	}

You can try to evaluate the code line by line in the popup console if you have basic JS knowledge.

But I think that's not the issue where is.
And yes you should be able to open the extension page this way.

I think it's more likely that there's a issue with some other part of the popup that's preventing further functionality.

One trick is that after you open the Inspect Element of the popup, press ⌘R(Command + R) in the interface, it will force reload the popup, see if any logs will appear in the console?

Then as @quoid said, use JS way to perform click operations in the console. (cause your interaction with the popup will cause both to close) But under normal circumstances, clicking the button will also cause both to close, but the extension page will be opened at the same time.

userscripts/src/popup/App.svelte

Line 587 in 4de92f7

<button class="link" on:click={() => { openExtensionPage(); window.close(); }}>

At the end, if you'd like, send us a screen recording of your operation process. This will help us check for any details you might not have noticed.

[ar-rm]

Thanks for the quick replies.

I am wondering if you would see an error in the background page if the openExtensionPage function failed from the popup...

Good thought.

Result:
No, I don't see any errors

You could try to open the browser dev tools for the popup by right clicking anywhere in the popup and selecting Inspect Element. From there you'd want to click Open Extension Page in the popup and see if any errors get logged, but I think doing that might close the popup.

Agreed. I've tried that too and you're right. The entire dev tools window closes.

Alternatively, once the dev tools open and you navigate to the console, you could run document.querySelector(".link").click() and see if anything gets logged.

Result:
Nothing

I also selected Open Extension Page and ran $0.click() with Open Extension Page selected.

Result:
The same. Dev tools closes and I don't see any errors.

Also, what OS version are you on?

macOS 12.6.5

(Sorry for leaving that out before.)

---

This is strange because the code for the button is fairly simple:

Agreed.

You can try to evaluate the code line by line in the popup console if you have basic JS knowledge.

I do. I'm also familiar with Svelte.

But I can't seem to get any type of readout because the dev tools closes too soon.

I've tried to set breakpoints, but again, it closes before I can inspect anything.

One trick is that after you open the Inspect Element of the popup, press ⌘R(Command + R) in the interface, it will force reload the popup, see if any logs will appear in the console?

Ahh. I didn't know about that.

Result:
No errors

At the end, if you'd like, send us a screen recording of your operation process. This will help us check for any details you might not have noticed.

I can do that eventually. But so far, there's nothing to report other than the button not working.

---

I was able to enable the All Events breakpoint in the Sources tab and then command-r (via the suggestion above).

It stopped in a few places but it was a little tricky to see what was going on because the popup-{hash}.js code is minified. But nothing weird jumped out at me (of course, I could be wrong).

The best I was able to generate was the following Warning in the console:

window.styleMedia is deprecated draft version of window.matchMedia API that is not implemented in Firefox and will be removed from the web platform in future.

[ACTCD]

I do. I'm also familiar with Svelte.
But I can't seem to get any type of readout because the dev tools closes too soon.

The problem is very strange if evaluating the original JS has no effect in the popup console.
And evaluating these codes should not close the console window immediately. (before executing the last 3 lines)
The console window should only disappear when the popup is closed. Which means unless a focus change occurs.
These APIs exist in the extension environment and can be executed directly, they have nothing to do with the popup code.
And, you can also execute the codes in the background page console.

browser.runtime.getURL("/dist/entry-page.html");

The above code should print out the URL of the extension page.
Or you pass window.location.href in the popup console and then manually splice the URL.
You can then paste it in the address bar of the new tab.
See if you can open the extension page.
Note that the extension URL will change every time you open Safari.
And the relative URL of the extension page will also change in future versions.

[ar-rm]

The console window should only disappear when the popup is closed. Which means unless a focus change occurs.

I'm not sure what role losing focus is playing. I've tried opening the Inspector and clicking around with other Extensions, and they too lose focus pretty easily.

But in in the case of Ghostery, I'm able to click a button to its Settings page, which spawns a new tab in the main window. Which is what I expect (and use to work) with Userscripts.

And, you can also execute the codes in the background page console.

browser.runtime.getURL("/dist/entry-page.html");

The above code should print out the URL of the extension page.

Yes! Very helpful.

This worked. I was able to manually get to the Extension Page via the URL that it returns.

If I run the following from within the Popup's Inspector window, the url is opened... in the actual toolbar popover. Ha! But that's expected.

window.location.href = browser.runtime.getURL("/dist/entry-page.html");

---

I did some more testing and was able to enable the event breakpoint directly on <button class="link">Open Extension Page</button>

Then I used document.querySelector(".link").click() to generate the event.

The debugger went to a spot in popup-{hash}.js.

The first part of the specifically highlighted code was:

const wt=()=>{Bt(),window.close()}

I searched the repo for window.close() and found 3x results

I think this (Line 583) is the unminified/non-compiled equivalent, given the back-to-back function calls:

userscripts/src/ext/action-popup/App.svelte

Lines 579 to 591 in d5f95bc

	{#if !inactive && platform === "macos"}
	<div class="footer">
	<button
	class="link"
	on:click={() => {
	openExtensionPage();
	window.close();
	}}
	>
	Open Extension Page
	</button>
	</div>
	{/if}

(Although I can't say that with certainty because of the Svelte compile process.)

The above code looks exactly right (go to the Extension Page and then close() the popup). The other instances of window.close() seem correct as well.

[ACTCD]

I'm not sure what role losing focus is playing. I've tried opening the Inspector and clicking around with other Extensions, and they too lose focus pretty easily.

What I mean is when the popup window loses focus, like if you click on anything outside the popup it will cause the popup to close. browser.tabs.create(); will lead to the same result.

This is a Safari issue and it does make debugging extension popups more difficult, but there's nothing we can do about it. All we can do is understand its quirks and possibly work around those inconveniences.

So when I suggest that you evaluate that code line by line, I expect that you should debug the return value of each line of code, not just evaluate them all.

So I still look forward to your debugging to see if there are other possibilities, such as the inability to query the corresponding tab through browser.tabs.query() or the inability to create the tab through the API.

As for the issue of code minimization, maybe we should study SourceMap to make debugging the code less difficult while maintaining the advantages of code minimization. (but probably should be limited to beta versions)

I think this (Line 583) is the unminified/non-compiled equivalent...

I've actually given in the comment above where the code for this version is, it's obvious. Note that you should never use the latest code in the main branch for reference, it is different from the extension version you are running.

[ar-rm]

So when I suggest that you evaluate that code line by line, I expect that you should debug the return value of each line of code, not just evaluate them all.

I had a feeling that's what you meant. I just wasn't looking forward to it :-)

In a relatively short amount of time, I was able to get the "Extension Page" to open as if it was triggered via the "Open Extension Page" button. But I think I'm going to need your help tracking down the precise reason.

Steps:

• Enable the breakpoint for all events on .link
• Go to the minimized popup.js in Sources
• Set a breakpoint on Line 10 (which contains the window.close() that I think is the culprit)
• Use $1.click() to trigger .link
• Step over a few functions until... Voilà!

Result:

• The popup closes and the "Extension page" opens in a new tab!

I have to repeat the steps above and copy the code that's highlighted just before the result. This is it:

, vt = () => t(6, f = !1), Ct = () => t(18, U = !1), yt = () => t(18, U = !1), It = () => { t(21, M = !1), ne() };
return r.$$.update = () => { r.$$.dirty[0] & 1 && t(24, l = i.sort((g, O) => g.name.localeCompare(O.name))), r.$$.dirty[0] & 2 && C && document.body.classList.add(C) }, [i, C, n, s, o, c, f, m, u, w, v, A, S, L, K, Z, q, z, U, y, W, M, le, te, l, b, $, ke, a, T, we, ne, ve, me, se, ut, at, _t, dt, mt, pt, bt, gt, ht, kt, wt, vt, Ct, yt, It]
}
class Ll extends ae { constructor(e) { super(), _e(this, e, Pl, Nl, de, {}, null, [-1, -1]) } } new Ll({ target: document.getElementById("app") });

I don't know why setting that breakpoint, and then stepping over (or into) the functions that followed, allowed the "Extension Page" to open.

I'm not sure how to track it down beyond this.

I hope this helps.

So I still look forward to your debugging to see if there are other possibilities, such as the inability to query the corresponding tab through browser.tabs.query() or the inability to create the tab through the API.

Running browser.tabs.query() in the console (while inspecting the popup) returns: Error: Invalid call to tabs.query(). A required argument is missing.

But I'm probably doing that wrong.

As for the issue of code minimization, maybe we should study SourceMap to make debugging the code less difficult while maintaining the advantages of code minimization. (but probably should be limited to beta versions)

👍🏻

[ACTCD]

window.close() that I think is the culprit

Yes, you reminded me of that, and I think that's the root cause of the issue.

We should:

{
	await openExtensionPage();
	window.close();
}

Otherwise, window closing may interrupt the previous async function.

But I'm probably doing that wrong.

Yes, I am just referencing the API, it is not the code that can be run directly. You need to refer to the original code line to fill in the parameters.

Anyway, thanks for helping us find the issue, I'll fix it in the next version.

[ACTCD]

@ar-rm Please try the latest beta version to see if your issue is resolved:
https://github.com/quoid/userscripts/releases/tag/v4.5.0-beta.5

Please note that in the beta version the settings page also has a new entrance in the Safari -> settings/preferences -> extensions.

[ar-rm]

window.close() that I think is the culprit

Yes, you reminded me of that, and I think that's the root cause of the issue.

We should:

{
  await openExtensionPage();
  window.close();
}

Otherwise, window closing may interrupt the previous async function.

Great idea.

But I'm probably doing that wrong.

Yes, I am just referencing the API, it is not the code that can be run directly.

It tripped me up because saw how browser, browser.tabs, and browser.tabs.query() are all available in the DevTools for the popup.

But as I found, don't work as I expected (and what you wrote).

Anyway, thanks for helping us find the issue, I'll fix it in the next version.

Cool. Thank you!

@ar-rm Please try the latest beta version to see if your issue is resolved: https://github.com/quoid/userscripts/releases/tag/v4.5.0-beta.5

✅ Confirmed working.

Please note that in the beta version the settings page also has a new entrance in the Safari -> settings/preferences -> extensions.

Good idea. I was thinking that too.

Also, thanks for enabling Source Maps:

So much nicer to debug :-)

It would be handy if they could be user-enabled in production builds (Maybe: In "Settings"?) because of exactly cases like this. But I can also understand why that might be a bad idea and maybe not even possible.

---

Thank you again for looking into this and for the very useful (and well made) extension.