Running document.getElementById( 'ca-edit' ).click(); shouldn't do anything, as #ca-edit is the <li> element, which does nothing when clicked.
You probably want to use document.querySelector( '#ca-edit a' ).click(); to click the <a> element inside it.

That said, it shouldn't throw an error either, and the fact that it does suggests that we made a very similar mistake in VisualEditor code, registering some event handlers on the wrong element.

The VE click handlers are registered on the li element.

(Also, while coding a userscript that is affected by this task, I decided to go this way because I assumed different skins might change the structure of the portlet links. Are they guaranteed to be the same so that your selector'd work across skins?)

Also, after some more testing, this only happens on Firefox. Chromium seems to set default parameters that are set to null.

Change #1168289 had a related patch set uploaded (by Aaron liu; author: Aaron liu):

[mediawiki/extensions/VisualEditor@wmf/1.45.0-wmf.9] DesktopArticleTarget: Restore null handling of url parameter

https://gerrit.wikimedia.org/r/1168289

Change #1168289 abandoned by Aaron liu:

[mediawiki/extensions/VisualEditor@wmf/1.45.0-wmf.9] DesktopArticleTarget: Restore null handling of url parameter

Reason:

Meant to target master branch

https://gerrit.wikimedia.org/r/1168289

Change #1168290 had a related patch set uploaded (by Aaron liu; author: Aaron liu):

[mediawiki/extensions/VisualEditor@master] DesktopArticleTarget: Restore null handling of url parameter

https://gerrit.wikimedia.org/r/1168290

Also, after some more testing, this only happens on Firefox. Chromium seems to set default parameters that are set to null.

I don't see this. Chrome 138.0.7204.94 (correctly, I think?) uses default parameters when passed undefined and not when passed other falsy values (e.g. null). So I get the same error you're experiencing:

Uncaught TypeError: Cannot read properties of null (reading 'searchParams')
    at trackActivateStart (ve.init.mw.DesktopArticleTarget.init.js:354:12)
    at activatePageTarget (ve.init.mw.DesktopArticleTarget.init.js:705:3)
    at Object.activateVe (ve.init.mw.DesktopArticleTarget.init.js:1157:4)
    at Object.onEditTabClick (ve.init.mw.DesktopArticleTarget.init.js:1125:11)
    at HTMLLIElement.dispatch (jquery.js:5145:27)
    at HTMLLIElement.<anonymous> (jquery.js:4949:28)
    at <anonymous>:1:38

As such, a reasonable alternative to your patch would seem to be to change ve.init.mw.DesktopArticleTarget.init.js line 1120 to have its fallback value be undefined instead of null.

Wait, that makes a lot of sense. I even thought of a blog post I saw on a developer deciding to phase out every "null" in their code while diagnosing the problem yet I didn't act on that recollection. I'll see what I can do when I wake up.

I can't reproduce this in Chromium (more precisely, Microsoft Edge) anymore either. I probably just accidentally clicked on the wrong element.

Change #1168290 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] DesktopArticleTarget: Fallback to undefined instead of null for linkUrl

https://gerrit.wikimedia.org/r/1168290