From Newsgroup: alt.comp.software.firefox

How to force Firefox to expose 'Edit Source' (Ctrl+U) in the context menu.

BACKGROUND:
Everything I do with Firefox I try to make a single step, if possible.
Each morning I click on scores of pre-prepared custom links in Firefox.

I use "control+U" when I need to edit the underlying HTML-bookmarked file.
That brings up the text HTML file in my favorite text editor (i.e., gVim).

This is possible because of Firefox native "view_source" configurations:
about:config
view_source.editor.external === true
view_source.editor.path === C:\app\editor\txt\vi\gvim.exe

This makes control+u pretty quick to edit the set of underlying links.
But, I need to make it even faster to EDIT the background set of links.

If something takes two steps, I reduce it to one step (if I can).
If it takes two seconds, I reduce it to one second (if possible).

That's what I'm attempting here by asking if it's native in Firefox.

I want the "control+U" (i.e., edit source) to be in the context menu.
Rightclick in the viewed bookmark file > Edit source

Currently, when I rightclick in the middle of the HTML display, I see:
Save page as
Select all
Take screenshot
View page source
Inspect accessibility properties
Inspect
Any of those can be cannibalized as they're not all that useful to me.

Can Firefox (Windows) natively cannibalize those context menu entries?
If not, I'll need to find an extension, but first, can FF do it natively?
--
Had I known how it works, I would have written up a tutorial instead since
I'm a rare breed of person who delights in edifying everyone around me.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

On Mon, 23 Feb 2026 14:02:15 -0600, Maria Sophia wrote:

How to force Firefox to expose 'Edit Source' (Ctrl+U) in the context
menu.

Quicker to just press CTRL-U. And actually itrCOs viewing the source,
not editing the source.

Note the context menu adds an option rCLView Selection SourcerCY if you
have any part of the page selected. This shows the source of the page
as it is rendered, not as it might originally have been read from the
server.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

Lawrence D Oliveiro wrote:

On Mon, 23 Feb 2026 14:02:15 -0600, Maria Sophia wrote:

How to force Firefox to expose 'Edit Source' (Ctrl+U) in the context
menu.

Quicker to just press CTRL-U. And actually it's viewing the source,
not editing the source.

Note the context menu adds an option |View Selection Sourcei if you
have any part of the page selected. This shows the source of the page
as it is rendered, not as it might originally have been read from the
server.

Hi Lawrence,

Thanks for hazarding help, as I know how dangerous that is on Usenet.
To me, it would be shocking if Firefox can't do something this simple.
a. Rightclick on empty space in a file://// URL
b. Click the context-menu entry "edit html"
c. That should do the same thing that Control+U does
(which, in my case, is *edit* the HTML source)

You helped a lot with the HTML-Fragment issue so I hesitate to correct
you here, but the way I have it set up, Control+U *edits* the file in gVim.

That's likely because I have set two variables different from default.
about:config
view_source.editor.external === true
view_source.editor.path === C:\app\editor\txt\vi\gvim.exe

Control+U is pretty quick, as you noted, but I want it even faster,
especially when I'm already got a hand on the mouse, not on the keyboard.

Since I couldn't find an easy native way to get Firefox to edit the
current HTML file from the context menu, and since I didn't want to
write my own extension, I tried (and failed) to use an existing
venerable extension.

Maybe I picked the wrong extension though, as it failed miserably
just now.

Apparently the rightclick context menu is defined in the browser UI code.
I can find no about:config key that exposes or modifies those menu entries.

Apparently (AFAICT):
a. "View Page Source" is hard-coded to call Firefox's internal viewer
b. It does not check view_source.editor.external
c. It cannot be replaced or redirected
d. Firefox does not allow adding new context-menu items through pref

Looking up how to do it non-natively, this extension isn't maintained:
<https://addons.mozilla.org/en-US/firefox/addon/open-with/>
"Quickly test out your web pages in Chrome, Edge, Safari, or Opera.
Open With opens the current page in your other browsers..."
"Open With is no longer maintained."
<https://addons.mozilla.org/firefox/downloads/file/3831723/open_with-7.2.6.xpi>
Name: C:\software\browser\ff\ext\openwith\openwithopen_with-7.2.6.xpi
Size: 410748 bytes (401 KiB)
SHA256: 7FD78684BC60E14C959F8A397B80D192B68B5B38F5D521ADA3F18EC2C25AF648

In Firefox, I went to "about:addons", clicked the gear icon & I selected "Install Add-on From File" from the context menu & selected "Add" & "OK".

To make Open With launch gVim, we must install the helper script.
But that helper script requires Python. Drat. Luckily, I have python.

where python

C:\app\os\python\python.exe
C:\Users\<me>\AppData\Local\Microsoft\WindowsApps\python.exe

python --version

Python 3.14.1

Now I need that helper script:
Firefox about:addons > Open With > ... > Options
Which says (and warns) verbatim...
To complete installation:
Open With needs a file outside of the browser to communicate with.
More information
<https://darktrojan.github.io/openwith/webextension.html>
You'll need to have Python installed for this to work.
Fetch it from here. <https://www.python.org/downloads/>
Click here to download
<moz-extension://57b9dfb2-f7ff-460a-a5d7-9af41598adef/native/open_with_windows.py>
and save the file to your computer.
Open a command prompt.
Run the file with the argument "install", like this:
open_with_windows.py install
If you move the file, you must run this step again.

Note that the moz-extension is apparently nothing like a normal URL.
It's a random, per-profile, per-installation UUID that Firefox generates locally.
It is kind of sort of like a pseudo virtual filesystem inside Firefox, I think. It downloaded this Python script:
Name: open_with_windows.py
Size: 4585 bytes (4 KiB)
SHA256: 453E93FA7BEC7B9BA28A7237875D375709FD0144A810AFE1C6BD0B2F26DC5BBA

Copy the open_with_windows.py file to your Firefox installation hierarchy.

mkdir c:\app\browser\ff\openwith
copy open_with_windows.py c:\app\browser\ff\openwith\.
python C:\app\browser\ff\openwith\open_with_windows.py install

That generated four JSON files and one batch file in the installation dir.
1. open_with.bat A tiny launcher that calls Python
2. open_with_chrome.json Native messaging manifest for Chrome (not used by Firefox).
3. open_with_chromium.json Same as above, for Chromium.
4. open_with_firefox.json This is apparently the one Firefox actually uses.
5. open_with_thunderbird.json Manifest, apparently for Thunderbird.

Press the "Test Installation" button in the "Open With" options inside Firefox:
"Found version 7.2.6 at C:\app\browser\firefox\openwith\open_with_windows.py." Point Firefox to any decent test page with whitestuff available.
<https://example.com/>
But a rightclick didn't show the expected additional context-menu entry.

Debugging with about:config > extensions.webextensions.restrictedDomains
accounts-static.cdn.mozilla.net
accounts.firefox.com
addons.cdn.mozilla.net
addons.mozilla.org
api.accounts.firefox.com
content.cdn.mozilla.net
discovery.addons.mozilla.org
install.mozilla.org
oauth.accounts.firefox.com
profile.accounts.firefox.com
support.mozilla.org
sync.services.mozilla.com
It's not blocked.

Debugging with about:debugging#/runtime/this-firefox
Open With
Extension ID === openwith@darktrojan.net
Internal UUID === 57b9dfb2-f7ff-460a-a5d7-9af41598adef
Manifest URL === moz-extension://57b9dfb2-f7ff-460a-a5d7-9af41598adef/manifest.json
[Inspect] > Console (is empty)
So Firefox is loading the extension shell, but not running its logic.

I could try to "patch" the extension, perhaps by doing the following to it:
a. Unzip the .xpi
b. Inspect manifest.json
c. Update it to "manifest_version": 3
d. Convert the background script to a service worker
e. Update the context-menu API calls
f. Repack it
g. Load it as a temporary extension

But I think I'll consider this "open with" a dead end (for now).
I'll try some other approach, whatever that may be.

I might try building my own extension, but that's ambitious.

And why should I have to. Can't Firefox do something this trivial?
i. Rightclick on the open space of a file:/// html
iii. Click on "Edit file" from the context menu

What's so impossible about that?
--
I rarely fail at getting any computer program to do what I want it to do.
But sometimes a program is so un-customizable, that even I eventually fail
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

Maria Sophia wrote:

I might try building my own extension, but that's ambitious.

Aurgh! <slaps head!> I fixed this years ago, and simply had forgotten!

Sometimes I get so immersed in fighting a problem that I don't step back
and look at it from a different angle, which just happened moments ago!

I was almost done building my own extension, when I accidentally clicked on "View page source" instead of on my extension "Open page source in gVim".
<https://i.postimg.cc/8Cw8Wg3W/edit-context-menu.jpg>

And the source to https://example.com came up in an editable gVim session! Likewise with the HTML text "file:///C:/data/amazon/vine.htm" file edits.

So, the ability to rightclick and *edit* the source was already there!
Mea culpa. My mistake. I went down a rathole for no good reason other than
I will never leet any application defeat me when I want it to do something.

Yet, in this case, I had already solved the problem. Years ago in fact.
I simply forgot that I already had the solution awaiting me all this time.

I had *forgotten* that these settings *also* affect the "View page source"
menu item, so the ability to edit from the context menu was *always* there!
about:config > view_source.editor
view_source.editor.external = true
view_source.editor.path = C:\app\editor\txt\vi\gvim.exe

Since I already wrote my first extension that does the same thing, I will
post a separate thread so that others can get the mechanics of extensions.

I'm working on the final step, which is Windows related, and not Firefox.

1. Extension loading
Working correctly. The background script loads, the context menu
is created, and the extension activates without errors.

2. Content script behavior
Working correctly. The background script sends GET_HTML,
the content script returns full HTML, and message passing is reliable.

3. Native messaging pipeline
Working correctly. Firefox finds the registry key, loads the JSON
manifest, launches the BAT file, and the BAT launches Python.

4. Python host behavior
Working correctly. The host receives messages, decodes JSON,
writes temp files, logs activity, and returns success responses.

5. Temp file creation
Working correctly. Each request produces a unique HTML file
in the system temp directory.

6. Editor launch command execution
Partially working. The subprocess call executes without errors,
but the editor window does not appear because it is launched
in a non-interactive desktop session.

7. Editor visibility
Not working. GUI editors launched directly from the native host
do not appear on the user's desktop. This is the final unresolved issue.

8. Required fix
Pending. On Windows, the editor must be launched using
"cmd.exe /c start"
to force it into the interactive session so the window becomes visible.

I'll write up that tutorial for Windows Firefox users separately so
that the two hours spent learning how to write my first extension
isn't completely wasted (I love teaching others how to do things).
--
Sometimes the best way to solve a problem is to step back and NOT solve it
for a while, and only after a bit of downtime, attack the problem ane
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

On Mon, 23 Feb 2026 20:22:59 -0600, Maria Sophia <mariasophia@comprehension.com> wrote:

Maria Sophia wrote:

I might try building my own extension, but that's ambitious.

Aurgh! <slaps head!> I fixed this years ago, and simply had forgotten!

Does that now restore peace and comfort for the rest of us following
this group?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

On Mon, 23 Feb 2026 20:22:59 -0600, Maria Sophia wrote:

I'll write up that tutorial for Windows Firefox users separately so
that the two hours spent learning how to write my first extension
isn't completely wasted (I love teaching others how to do things).

I suspect that the Venn diagram of rCLHackerrCY versus rCLuses Microsoft WindowsrCY shows a dwindling overlap ...
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

Lawrence D'Oliveiro wrote:

On Mon, 23 Feb 2026 20:22:59 -0600, Maria Sophia wrote:

I'll write up that tutorial for Windows Firefox users separately so
that the two hours spent learning how to write my first extension
isn't completely wasted (I love teaching others how to do things).

I suspect that the Venn diagram of "Hacker" versus "uses Microsoft
Windows" shows a dwindling overlap ...

Hi Lawrence,

Thanks for being helpful where I learned a lot writing my first extension.

Like most here, I "grew up" in the days well before Linux existed, so every computer I ever worked on had more "hacker" capacity than does Windows.

But today, I'm using Windows, as I don't dual boot to Linux anymore.

Still, I learned something useful which is that it's not hard to write your
own Firefox extension. called from your own Firefox context menu item,
which then calls any program you want it to call on your desired platform.

That took about two or three hours (if you count writing the tutorial). Everyone else can follow my tutorial and be successful in five minutes.

That's value added, is it not.
Anyway, I am confident my extension would have worked on Linux.
Even as I'm "stuck" on Windows.

The current status of my first Firefox extension is that...
1. The extension works.
2. The native host works.
3. The Python host works.
4. The temp file creation works.
5. The JSON messaging works.
6. The BAT file works.
7. The editor launch command runs.
8. Everything is appropriately logged to debug files.
9. But Windows refuses to launch ANY GUI editor from the native host.

Maybe Linux will?
Dunno.

We know that Firefox "can" launch an editor from the context menu.
Because Firefox's built-in "View Page Source" *does* pop up the $EDITOR!
view_source.editor.external = true
view_source.editor.path = C:\app\editor\txt\vi\gvim.exe

Yet, my extension works fine but just won't pop up the Windows $EDITOR.
What's the difference?
Both are trying to spawn an editor in Windows for the current page source?

The built-in Firefox feature
a. runs in my interactive desktop session
b. is not sandboxed
c. is not restricted
d. can launch GUI apps normally

Yet, my extension's native host:
a. runs in a restricted background process
b. cannot launch GUI apps into your desktop
c. cannot show windows
d. cannot spawn interactive editors

I don't (yet) know enough about writing extensions to figure out why.
Maybe on Linux it would have worked. Dunno why the editor won't pop up.

I'll post a query on the Windows newsgroup asking if there's a solution.
In that query, I'll post all my source code so all always benefit.

I think it's a great project and honestly, we're in a better position to
write this tutorial than most people who've ever tried to build a Firefox extension on Windows. We've lived through the exact pain points that trip
up new developers, and we've discovered the one big "gotcha" that almost no documentation warns about, which is that native messaging hosts on Windows cannot reliably launch GUI applications into the user's desktop session.

This tremendous added value is the kind of real-world insight that makes a tutorial valuable rather than another "hello world" clone, don't you think?

Newsgroups: alt.comp.software.firefox,alt.comp.os.windows-10,alt.os.linux
Subject: Tutorial: Firefox rightrCaclick extension + native host on Windows (GUI launch mystery)
Date: Mon, 23 Feb 2026 21:48:15 -0600
Message-ID: <10nj71v$22in$1@nnrp.usenet.blueworldhosting.com>
--
Sometimes you need help from others to check what you did, but on Linux.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

On Mon, 23 Feb 2026 20:22:59 -0600, Maria Sophia wrote:

Maria Sophia wrote:

I might try building my own extension, but that's ambitious.

Aurgh! <slaps head!> I fixed this years ago, and simply had forgotten!

Sometimes I get so immersed in fighting a problem that I don't step back
and look at it from a different angle, which just happened moments ago!

I was almost done building my own extension, when I accidentally clicked on "View page source" instead of on my extension "Open page source in gVim".
<https://i.postimg.cc/8Cw8Wg3W/edit-context-menu.jpg>

And the source to https://example.com came up in an editable gVim session! Likewise with the HTML text "file:///C:/data/amazon/vine.htm" file edits.

So, the ability to rightclick and *edit* the source was already there!
Mea culpa. My mistake. I went down a rathole for no good reason other than
I will never leet any application defeat me when I want it to do something.

Yet, in this case, I had already solved the problem. Years ago in fact.
I simply forgot that I already had the solution awaiting me all this time.

I had *forgotten* that these settings *also* affect the "View page source" menu item, so the ability to edit from the context menu was *always* there!
about:config > view_source.editor
view_source.editor.external = true
view_source.editor.path = C:\app\editor\txt\vi\gvim.exe

Since I already wrote my first extension that does the same thing, I will post a separate thread so that others can get the mechanics of extensions.

I'm working on the final step, which is Windows related, and not Firefox.

1. Extension loading
Working correctly. The background script loads, the context menu
is created, and the extension activates without errors.

2. Content script behavior
Working correctly. The background script sends GET_HTML,
the content script returns full HTML, and message passing is reliable.

3. Native messaging pipeline
Working correctly. Firefox finds the registry key, loads the JSON
manifest, launches the BAT file, and the BAT launches Python.

4. Python host behavior
Working correctly. The host receives messages, decodes JSON,
writes temp files, logs activity, and returns success responses.

5. Temp file creation
Working correctly. Each request produces a unique HTML file
in the system temp directory.

6. Editor launch command execution
Partially working. The subprocess call executes without errors,
but the editor window does not appear because it is launched
in a non-interactive desktop session.

7. Editor visibility
Not working. GUI editors launched directly from the native host
do not appear on the user's desktop. This is the final unresolved issue.

8. Required fix
Pending. On Windows, the editor must be launched using
"cmd.exe /c start"
to force it into the interactive session so the window becomes visible.

I'll write up that tutorial for Windows Firefox users separately so
that the two hours spent learning how to write my first extension
isn't completely wasted (I love teaching others how to do things).

I actually use custom protocol (e.g. `external:`) for adding bookmarks and bookmarklets which runs external application. IMO, it's much simpler and
easier to maintain & extend. Albeit not as context menu items.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

JJ wrote:

I actually use custom protocol (e.g. 'external:') for adding bookmarks and bookmarklets which runs external application. IMO, it's much simpler and easier to maintain & extend. Albeit not as context menu items.

Hi JJ,

Thanks for adding value by describing how you made FF more efficient.

Your custom-protocol method makes sense, if I understand your workflow.

By registering a protocol in the OS, then pointing it at an external
program, you can create a bookmark that starts with something like

external:somefile

and Firefox will hand that off to the system, which then launches the
handler you registered. That gives you a simple way to trigger an editor or
a script without needing an extension and without touching the Firefox
context menu like I was doing (not remembering I solved it years ago).

As you noticed, yours is a different workflow than what I was solving,
since my goal was to keep the edit action tied to the existing View page
source entry, yet your method is a clean example of how far protocol
handlers can go when someone wants a lightweight, easy-to-maintain setup.

For Linux users like Lawrence, the same idea likely works there too.

Instead of registry keys, Linux uses a .desktop file that declares an x-scheme-handler for the custom protocol. Once that file is installed under ~/.local/share/applications or /usr/share/applications and the MIME
database is updated, Firefox will likely hand external: URLs to the system
just as it does on Windows. The system then launches whatever command is
listed in the .desktop file. Same concept, different plumbing.

I appreciate you adding that angle. It is always useful to see how others streamline their tools, especially when the solution adds efficiency.
--
Intelligent people can always come up with many solutions to any problem.
It's the dumbshits who always fall prey to what marketing tells them to do.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

Summary of what I (we?) learned from the erudite discussion on this thread.

1. I had originally wanted Firefox to expose edit source in the context
menu so editing HTML files in gVim would be a one step action.

This was to reduce every action with Firefox to a single quick step.

Particularly in my case where I write hundreds of Vine reviews/year.
<https://amazon.com/vine/about>
It's important to get the jump on other Vine reviewers on Amazon.
(see syntax explanation appended at the end of this post)

2. Firefox already supports this. The view_source.editor settings apply
to both control+U and the View page source menu entry. I had already
solved this years earlier and forgot edit works in the menu also.

control+U (edits the search file of the format)

3. The extension work was eventually successful. Background script,
content script, native messaging, Python host, debugging logs
and temp file creation all worked. The original stumbling block
was that GUI editors launched from the native host were invisible
on Windows (but likely visible on Linux).

Lawrence wryly noted Windows is often substandard to Linux when
it comes to being able to always get done what you want to do.

4. JJ described an alternative method using a custom protocol such as
external:. Registering a protocol handler lets a bookmark launch an
external program without an extension. On Linux the same idea works
with a .desktop file that declares an x-scheme-handler.

5. The broader lesson is that Firefox already provided the needed
one step edit action for *both* the keyboard sequence (Ctrl+U)
and the context menu (View source -> Edit source), once the
appropriate view_source.editor settings were in place.

6. The subsequent Linux/Windows Firefox extension example became a
learning exercise rather than a workaround requirement.

Newsgroups: alt.comp.software.firefox,alt.comp.os.windows-10,alt.os.linux
Subject: Tutorial: Firefox right-click extension + native host on Windows (GUI launch mystery)
Date: Mon, 23 Feb 2026 21:48:15 -0600
Message-ID: <10nj71v$22in$1@nnrp.usenet.blueworldhosting.com>

As an aside, following is an explanation of the original problem set.

I order hundreds of 'free' items off of Amazon Vine where, just a few
months ago, there were ten times the number of items to select from,
but now, for some odd reason, new-product shipments from China
have dried up to about a tenth of what the daily offering was prior.

Perhaps as a result, Amazon has been laying off the low-quality Vine
reviewers, but there are still more reviewers than product at this point.
<https://amazon.com/vine/about>

When products gets added in a tidal wave effect starting at around 8:30am
Eastern Time, there is a mass click storm that grabs the good stuff first.

The search engines for Amazon are absolutely horrid (probably on purpose),
where you have to keep it super simple, like "gasoline" or "tr21-4" to
find parts for your home fueling station or for your carbonation racks.
<A HREF=https://amazon.com/vine/vine-items?search=gasoline>gasoline</A>
<A HREF=https://amazon.com/vine/vine-items?search=tr21-4>tr21-4</A>

That syntax won't work if you're not on Vine, so here are examples:
<A HREF=https://www.amazon.com/s?k=fuel+transfer+hose>fuel hose</A>
<A HREF=https://www.amazon.com/s?k=cga320+tr21-4>carbonation adapter</A>

Note that you can be far more explicit on the native Amazon search engine,
whereas you can't be specific at all on the much-worse Vine search engine.

So how do I get a jump on the other Amazon Vine reviewers at 8:30am?
What I maintain is a vine.html text file, containing the search terms.

In the morning, I click through the vine.html in Firefox, although only
about a half dozen clics at a time as Amazon limits the clicks per second.

So the vine.html text file is organized in half-dozen increments.
(I'll convert to Amazon links but they're Vine-syntax in my text file.)

<A HREF=https://www.amazon.com/s?k=gfci+adapter>gfci adapter</A>,
<A HREF=https://www.amazon.com/s?k=co2+adapter>co2 adapter</A>,
<A HREF=https://www.amazon.com/s?k=6-20+adapter>nema 6-20 adapter</A>,
<A HREF=https://www.amazon.com/s?k=l14-30+adapter>nema l14-30 adapter</A>,
<A HREF=https://www.amazon.com/s?k=usb+adapter>usb adapter</A>,


So I need to be fast; but not too fast, to get the jump on the product.
I need to be able to extend my vine.htm file at the click of a button.
--
If something takes two steps, I reduce it to one step (if I can).
If it takes two seconds, I reduce it to one second (if possible).
Only in quantum mechanics can you go lower-level than that.
--- Synchronet 3.21b-Linux NewsLink 1.2