these were moved to a utility class and converted from plain functions
to class methods. because BrowserCommands.reload*() calls
this.reloadWithFlags(...), we can't use (a or b)() as that clobbers the
scope of `this`. that could be worked around like so, but that's horrid:
(vim.window.BrowserCommands?.reload.bind(vim.window.BrowserCommands) or vim.window.BrowserReload)()
girst [Fri, 8 Mar 2024 15:07:16 +0000 (16:07 +0100)]
update external documentation hyperlinks
sadly, a lot of interesting stuff has just evaporated.
* Browser is no a custom element (MozBrowser)
https://searchfox.org/mozilla-central/source/toolkit/content/widgets/browser-custom-element.js
* Services.jsm is now built into the C++ core
https://bugzilla.mozilla.org/show_bug.cgi?id=1464542
girst [Sun, 25 Feb 2024 15:14:49 +0000 (16:14 +0100)]
populate more data in contentAreaClick
Bug 1800149 introduced ClickHandlerParent.fillInClickEvent() which we
just inline. Previously, mozilla passed these params from the content
process, which could be a problem if the content process was compromised
Note that this code does not work with mozilla68 because
window.browsingContext was only introduced afterwards.
Further, for documentation:
* until mozilla110, isContentWindowPrivate was calculated differently:
https://hg.mozilla.org/mozilla-central/rev/a868f954be08#l1.51
* frameID used to use the same code as frameOuterWindowID in <=fx110:
WebNavigationFrames.getFrameId(window.document.defaultView)
girst [Sun, 25 Feb 2024 14:28:58 +0000 (15:28 +0100)]
improve contentAreaClick
This adds a few missing options used by BrowserUtils.whereToOpenLink, as
well as finally passing CSP and ReferrerInfo. Unlike Mozilla, we call
contentAreaClick directly from the parent process (they from
ClickHandlerChild), so we don't need to serialize/deserialize these
objects. However, they get CSP from event.originalTarget.ownerDocument
and try to init ReferrerInfo from initWithNode(event.composedTarget),
neither of which we have access to from the parent process.
Note that referrerInfo.initWithDocument() was introduced with mozilla69:
https://hg.mozilla.org/mozilla-central/rev/b5df2e6d8478cb4aea88d109259714ca2772b6cd#l1.29
girst [Sun, 25 Feb 2024 11:36:49 +0000 (12:36 +0100)]
stop relying on AddonManager.jsm for retrieving homepageURL
this was always brittle (e.g. restarting the browser with the options
page open would try to access homepageURL before it was available/loaded
from async).
girst [Tue, 29 Aug 2023 17:04:12 +0000 (19:04 +0200)]
(half/full) page scrolling: don't take position:absolute headers into account
Github's new code view[1] places each line of code visible on screen, as
well as some above and below, as a position:absolute element (within a
position:relative parent). Our code did not check whether such an
element is absolute w.r.t the current scrolling viewport or some other
element and would horribly miscalculate the amount to scroll: It would
take all off-screen position:absolute elements and add their heights,
then subtract that from the amount to scroll; even turning the scoll
amount negative!
Further,
* medium[.]com does not appear to use any footer any more, and
* the website mentioned in #698, inbound[.]org no longer resolves.
The referenced Firefox implementation doesn't check position:absolute
elements at all. As an actual improvement, Firefox now actually checks
for position:sticky elements, but only when they are 'stuck' (and
therefore behaving like position:fixed)[2]. They use some Gecko
internals, but this could be implemented in VimFx using something along
the lines of this:
girst [Fri, 9 Jun 2023 14:10:45 +0000 (16:10 +0200)]
fix sandbox detection
this was backwads. filesystem reads are blocked on level 3 or above.
also renaming this function to better capture what it does (returns true
if sandbox likely prevents config file access).
see also: https://wiki.mozilla.org/Security/Sandbox#Linux
https://searchfox.org/mozilla-central/search?q=security.sandbox.content.level&path=browser%2Fapp%2Fprofile%2Ffirefox.js
girst [Sat, 3 Jun 2023 13:36:23 +0000 (15:36 +0200)]
fix utils.isInShadowRoot
At some point before firefox 84, the global `ShadowRoot` object stopped
being === to the ShadowRoot returned by utils.getDocument. this caused
following links to not work because the special code paths for elements
within shadow roots was not taken any longer.
The check whether ShadowRoot is defined can be safely dropped, since
even though ChromeWindow doesn't export ShadowRoot itself, accessing it
through element.ownerGlobal still works.
girst [Fri, 11 Nov 2022 13:56:23 +0000 (14:56 +0100)]
fix installation on localized/l10n versions of firefox
resource://gre/modules/addons/XPIInstall.jsm tries to get the Addon's
name in loadManifest(). On localized versions supported by VimFx, this
is read from install.rdf's <em:localized> section. We assumed that when
this block does not include an <em:name> element, that it would use the
one from the non-localized section. That does not seem to have been
true, ever. Even l10n-Firefox 52 balks here (using 0.21.0 and 0.22.2),
as well as i10n-Firefox 68.
girst [Fri, 12 Aug 2022 20:55:39 +0000 (22:55 +0200)]
fix 'eb'
even though Bug 1415483 suggests that calling importGlobalProperties is
no longer needed for Element, we run into a ReferenceError unless we do
call it. Even stranger, executing this in the Browser Sandbox (where
Element is already defined) causes a NS_ERROR_NOT_AVAILABLE exception.
- nsIDOMElement was removed in mozilla61 in Bug 1455674
- call to importGlobalProperties was made unnecessary in mozilla65 in
Bug 1489301 part 4 (see also: Bug 1501127)
move from deprecated Cu.import to ChromeUtils.import
In most cases, this was a drop-in replacement, but in bootstrap.coffee,
we used the side effect of polluting the global namespace as a handy way
to inject the `Services` object into the user's config.js file.
As a bonus, the codebase has been rid of an inconsistency between
Components.utils.import() and its shorthand Cu.import(), since both are
now gone. We also use the destructuring assignment consistently now.
Both config.js and frame.js were checked to still have the same exposed
API (mainly concerned with Services and console, since that was removed
from bootstrap.coffee).
girst [Fri, 28 Jan 2022 14:02:41 +0000 (15:02 +0100)]
Move contentAreaClick() to utils
We use this opportunity to rename json to data, as per
https://hg.mozilla.org/mozilla-central/rev/65905c6fcf34cd35ed433da3076eb8056b5d1a63
Note that we keep passing in the browser object, though.
Alex Nguyen [Sun, 19 Sep 2021 03:21:49 +0000 (13:21 +1000)]
update support for user contexts (containers)
This change was made to fix issues with following links via firefox
containers.
If old tab was in a container, new tab would be created without one.
The usercontextid attribute was found via debugging set up and exploring
for properties that correspond to the current container.
girst [Wed, 4 Aug 2021 18:09:11 +0000 (20:09 +0200)]
Note where contentAreaClick's allowMixedContent came from
There was a new commit, 32025eb4c69c59e6a84c62ce262c4a7d2cd457de, to
ClickHandlerParent.jsm (bailing if browser is null). This one doesn't
apply to us, since this can only happen in asnyc/postMessage-triggered
contexts.
girst [Sun, 22 Nov 2020 15:03:29 +0000 (16:03 +0100)]
Do not inject Console.jsm into frame scripts
causes some errors in the browser console
TypeError: console.createInstance is not a function 3 E10SUtils.jsm:297:27
log resource://gre/modules/E10SUtils.jsm:297
shouldLoadURI resource://gre/modules/E10SUtils.jsm:955
shouldLoadURI chrome://browser/content/tab-content.js:45
TypeError: log is not a function LoginManagerChild.jsm:813:8
onDOMFormHasPassword resource://gre/modules/LoginManagerChild.jsm:813
handleEvent resource://gre/modules/LoginManagerChild.jsm:673
TypeError: log is undefined LoginFormFactory.jsm:68:5
createFromForm resource://gre/modules/LoginFormFactory.jsm:68
createFromField resource://gre/modules/LoginFormFactory.jsm:110
handleEvent resource://gre/modules/LoginManagerChild.jsm:684
girst [Tue, 5 May 2020 12:18:53 +0000 (14:18 +0200)]
Don't crash on pages with out-of-process iframes when fission is enabled
This should be considered at most a workaround; oop iframes are
completely opaque to VimFx. This not only means that hints are not
generated for elements inside them, but also that VimFx can't detect
when an input element is focused. Due to the latter, we switch to insert
mode whenever we detect that focus is inside an OOP iframe, so text
inputs can still be used.
During implementation, a bug (https://bugzilla.mozilla.org/1635530) was
found (and filed) where activeElement was wrong. This is fixed as of
Firefox 78. Given that fission is still disabled by default, earlier
verisons aren't affected.
Note: lib/utils.coffee::getTopOffset() also accesses frameElement, but
that's safe, since this function is only called by
simulateMouseEvents(), which only works on elements that were previously
reached via hints mode (where we already check for oop iframes).
lib/utils.coffee::containsDeep() is also safe, albeit less so. It is
called through lib/scrollable-elements.coffee::addChecked()
by lib/events-frame.coffee's addEventHandler('overflow'), which as of
fx78 does not receive events from OOP frames.
keeping old value around to stay backwards-compatible. upstream change:
https://hg.mozilla.org/mozilla-central/diff/48564fee92c70018cae91b914cb7529c86edecb7/browser/actors/ClickHandlerParent.jsm
girst [Tue, 5 May 2020 12:07:34 +0000 (14:07 +0200)]
Fix getting stuck in normal mode in docked DevTools after refocusing
In Nightly 70 the docked DevTools were switched from a Chrome Frame to a
Content Frame. The part of VimFx that determines what is part of the
browser UI (to work around a bug regarding delayed ipc messages) then
didn't recognize the DevTools as part of the UI any longer.
When a focusType event comes from the browser UI, a second event is
fired erroneously a few milliseconds later. This caused us to enter
insert mode in the devtools, and immediately exit out of it again,
making it impossible to type in e.g. the style editor.
STR:
1. open devtools->style editor (or ->network)
2. focus textbox (vimfx icon will turn silver)
3. focus webpage (vimfx switches to normal mode)
4. focus style editor (vimfx fails to return to ignore mode)
Unrelated to this change, the about:devtools-toolbox's chrome document
was renamed from .xul to .xhtml a few releases back. This second URI was
added; no idea if its absence broke anything.
girst [Thu, 30 Jan 2020 22:05:33 +0000 (23:05 +0100)]
Fix GitHub search box hint
Github has wrapped the input field in a div with aria attributes, but
the trigger is actually attached to the input itself. Since they share
the same position, the useless hint for the div is displayed on top of
the useful hint of the input.
Minimal test case:
<div role="combobox">
<input name="q" onclick="void 0">
</div>
girst [Tue, 31 Dec 2019 16:44:37 +0000 (17:44 +0100)]
Ignore error thrown by dispatchDOMEvent
Triggered e.g. by `f`-ing on an extension card's description/title. The
click still registers, so it's just noise in the log. This bug is
present in all supported versions (at least 68..73), but unlikely to be
fixed, as it is "only" a testing function (and we're not supposed to use
it).
NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMWindowUtils.dispatchDOMEventViaPresShellForTesting]
girst [Fri, 27 Dec 2019 01:09:05 +0000 (02:09 +0100)]
Remove last isXULDocument() references
== commands.follow ==
On XUL pages/windows, <body> does not exist (hence the check was put
in), but is `null`, so can be safely compared against (and the check can
be omitted).
== helper_follow ==
Since the last war on isXULDocument, the namespace has in many cases
been moved from the document root to a descendant (e.g. to <body> on
about:preferences in fx73). This means that the isXULDocument call often
isn't triggered when it should.
Coincidentally, most XULElements are recognized, either due to them
being implemented as a custom element containing a recognized element or
by their tag name being identical to a recognized one. The only
exception is <xul:label is="text-link">, which needed special handling
in commands.follow_in_tab().
girst [Thu, 5 Dec 2019 20:06:52 +0000 (21:06 +0100)]
update "vulnerable" packages
vi package.json && npm install && npm audit fix && git commit -A
to make this new github bot shut up, hopefully. none of these packages
are included in the final xpi, and the build doesn't change, so it
doesn't matter either way. the addon-linter package was fixed to 0.24.0,
which is the last version that supports install.rdf without throwing a
warning.
girst [Mon, 2 Dec 2019 14:36:43 +0000 (15:36 +0100)]
replace imported ContentClick module with stub
The module was replaced at the very end of the 72 cycle with
ClickHandlerParent.jsm, which made contentAreaClick non-static. It would
have been technically possible to just ship the old module with either
VimFx or LegacFox, but since it is so small and it was replaced to
support Fission, it seemed better to extract the relevant parts of the
method and just inline them. We'll need to keep it up-to-date either
way.
Note that despite this we are _not_ fission compatible; when a 3rd-party
iframe is present, hints mode breaks.
girst [Sun, 1 Dec 2019 20:23:28 +0000 (21:23 +0100)]
fix 'modifiers is null' TypeError
element.getAttribute() might return null, while
xulElement.getAttribute() returns the empty string. the latter is
expected by the implementation. Since fx71, the main window is now an
HTMLDocument instead of a XULDocument, causing the breakage.
girst [Sun, 1 Dec 2019 17:57:09 +0000 (18:57 +0100)]
Remove misuse of isXULDocument()
A new isXULElement() has been introduced as a replacement for improper
use of isXULDocument() (where the latter was used to indirectly check
the former). isXULDocument() only works if the xul-xmlns is attached to
the document as its main namespace, which is not the case e.g. on fx72's
about:preferences#sync (the test for which now uses isXULElement).
The test in isProperLink() actually wants to know if an element belongs
to the XUL namespace, not if it is embedded in a document of that NS
(to treat <xul:label is="text-link"> element equivalent to <html:a>).
The blurring condition in events-frame.coffee was introduced in e881629
for about:config, but that does not work any more and is also annoying
on :prefs (and was again an indirect test for what was actually wanted).
In commands-frame.coffee's commands.follow(), two of the three uses of
isXULDocument have been replaced by the proper isXULElement, the third
one is likely to be correct (as there isn't a <body> on xul-<window>s).
This leaves us with 1 remaining unclean use, in commands-frame.coffee's
helper_follow(). It is used to catch all the xul elements that have html
equivalents with different tag names. Replacing that with something
proper will not be attempted in this change, as it would probably
require changing its callers to pass in different arguments when ran in
the XUL namespace.
girst [Sun, 1 Dec 2019 17:51:05 +0000 (18:51 +0100)]
undo useless hint exclusion
this was originally introduced to "remove unnecessary hints markers in
the addon manager"(@94f5252), but about:addons has since been rewritten
and this actually breaks the search box on about:preferences and
about:addons, as well as on the old xul-about:config.
girst [Wed, 27 Nov 2019 21:10:58 +0000 (22:10 +0100)]
Require Firefox 68 and Update Documentation
since the removal of the XBL-aware getAllElements() code path, this
extension is less useful on .xul pages (i.e. some about: pages) in older
Firefoxen. Users of older versions of Firefox (or derivatives) should
stay on v0.22.2. While nobody is stopping you from downgrading or
ignoring the min-version requirement, you don't gain any new
functionality and might have a degraded experience with v0.23.x.
girst [Thu, 21 Nov 2019 15:47:49 +0000 (16:47 +0100)]
remove getAnonymousNodes() code path from getAllElements()
in fx68 and newer, there are no in-content bindings (i.e. those in .xul
about:-pages) left, and hardly any that are reachable via VimFx hints.
The only element with anonymous nodes that was reachable that way is the
(non-megabar) URL bar, which is better focused using 'o'.
The other now removed function, getBindingParent(), will have to stay;
otherwise custom elements (e.g. on bugs.chromium.org or the <xul:tree>
element on XUL-about:config) won't be properly clickable through hints.
the whole XULDocument code path in
markable-elements.coffee::getAllElements() is now obsolete, since
getAnonymousNodes() no longer exists, and before that, returned nothing
of importance, since most XBL bindings have been removed before Firefox
68. Removal of the code path will follow in a follow up to ease a
possible revert, since a very small amount of hints might get lost in
68esr without it (the only concrete example I've found is the urlbar in
'eb' mode, which can also be reached with 'o').
girst [Sat, 16 Nov 2019 12:35:55 +0000 (13:35 +0100)]
new release script
inspired by
https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/
and https://drewdevault.com/2019/10/12/how-to-fuck-up-releases.html
care has been taken to make it posix compliant. however, it does by
default depend on my fairly unusual setup to be present, which can
however be easily overridden (see script for details).
girst [Sat, 16 Nov 2019 11:40:18 +0000 (12:40 +0100)]
fix 'eb' for nightly72
browser.xhtml now uses a <html> (was a <xul:window>) element as its
root. since the ID we anchored to was assigned to <html>, we added the
hints as a sibling to the body instead of below it.
git://git.gir.st / VimFx.git / log