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.
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.
girst [Sat, 19 Oct 2019 17:33:08 +0000 (19:33 +0200)]
fix 'eb' for fx71
browser.xhtml was restructured between firefox 69 and 71, and hints were
not displaying any more (they still worked, adding to the confusion). It
turns out that moving the hints-containert before #navigator-toolbox is
sufficient. But insertBefore()ing that element breaks Waterfox 56, as
this element does not exist there (which is a bit strange, as the docs
say, insertBefore should degrade gracefully to appendChild in such a
case). However, we can just insert it as the first element below
the #main-window element, which works a treat.
girst [Sat, 24 Aug 2019 00:55:41 +0000 (02:55 +0200)]
experimental custom-element support
Web Components / HTML5 Custom Elements were previously inaccessible to
VimFx. Examples of heavy users of this technology is about:logins
(Firefox 70) and bugs.chromium.org. Elements within the shadow DOM were
unable to be selected with hints mode.
VimFx' non-XUL DOM traversal routine was extended to not only search the
(regular) DOM, but also check each element if it contains an open shadow
DOM, and traverse it too. Interestingly, getElementsByTagName is not
defined by the DocumentOrShadowRoot class, only querySelectorAll.
Further, it appears that the native C++ function VimFx uses to send key
events to clickable elements is unable to be used inside the shadow DOM,
resulting in the error message below.
NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMWindowUtils.dispatchDOMEventViaPresShell] utils.js:291
NOTE: This regression has made it obvious that VimFx uses isXULDocument
to make assumptions about the document it is looking at that no longer
hold when WebComponents are involved. More might be unearthed in the
future.
NOTE: the URL for an entry in about:logins is not clickable, as it is a
read-only text input with an onclick handler, instead of a link. That
edge case is not handled by utils.isTypingElement().
girst [Tue, 20 Aug 2019 17:38:10 +0000 (19:38 +0200)]
fix hints mode on about:addons and about:preferences in nightly 70
In Bug 1550801, all XUL documents were loaded as HTMLDocuments, which
caused the isXULDocument test to fail. The new test is modeled after a
snippet from devtools/.
This change caused hints mode to break in about:preferences and
about:addons, since (some of?) the de-XBL'd custom elements' <label>s
return the id (as string) when reading theLabelElement.control on a
label instead of an HTMLElement. VimFx passes this value to a function
that assumes the value has a .getClientRects() method.
Only these two pages were affected, since these are the only in-content
pages (other than about:downloads) in Firefox 70 that still have a .xul
document at the root.
girst [Thu, 15 Aug 2019 10:07:01 +0000 (12:07 +0200)]
Taking over maintainership
There's a new maintainer in town. While new features won't be developed,
VimFx will continue to work on Firefox Quantum and its derivatives for
the forseeable future.
girst [Mon, 5 Aug 2019 01:25:43 +0000 (03:25 +0200)]
Port settings page to a modern format
Inline-settings have been dropped in http://bugzil.la/1414406. At the
same time, the <setting> XBL binding has been removed. Here, we recreate
the settings page using (X)HTML opening in a new tab.
The XBL converter (bgrins/xbl-analysis@564f6e402a) was helpful in
reconstructing the <setting> element and the new aboutconfig.js has a
good observer example at the end (-> central@4d5f1517ef85).
girst [Thu, 1 Aug 2019 09:42:02 +0000 (11:42 +0200)]
fix hints mode and help popups
entering any of these modes adds an overlay above the <browser> element.
In mozilla69 the style property 'display: -moz-box' was removed from '*'
in minimal-xul.css. When the overlay was displayed without this
property, the <browser> would be resized to 25x25px to make room for the
overlay instead of displaying them on top of each other.
girst [Thu, 1 Aug 2019 09:06:27 +0000 (11:06 +0200)]
replace custom status panel with default one
In Mozilla's efforts to get rid of XBL[1] they changed the way the
status panel works. Up to Firefox 68, the changes meant that the panel
just didn't show up, but with Firefox 69 and onwards, it broke the
display of the browser. This change replaces the custom (secondary)
status bar and uses the main one for displaying infos and errors.
See also: bug[2] and changeset[3] of the removal of <statusbar>
When hitting esc a TypeError was shown in the browser console
(Ctrl-Shift-J), except when an element is fullscreened. The location of
the error (i.e. commands-frame.js:621) is only shown on special pages
(like about:* or chrome://), making the problem harder to locate.
see also: functionality introduced in commit ab17744
> TypeError: The expression cannot be converted to return the specified type. commands-frame.js:621
Remove dependency on non-standard Array.some() and Array.filter()
Also replaces the deprecated DOMQuad.bounds.
Firefox 70 will remove[1] non-standard Array generics[2][3]. These were
identified using the following shell pipeline:
cd VimFx/extension
grep -rn 'Array\.' | grep -v '\.isArray\|\.of\|\.from\|\.prototype'
girst [Sun, 12 May 2019 13:15:30 +0000 (15:15 +0200)]
fix hintsmode clicking in ff56, squash some exceptions
Some uses of the deprecated Array.func() syntax are, despite the browser
console telling us, not replacable by Array.prototype.func(). Also
silenced some exceptions that are expected.
girst [Sun, 12 May 2019 12:35:27 +0000 (14:35 +0200)]
partial fix for `eb'
the vbox#browser-panel element was removed and its children
(#navigator-toolbox, #content-deck, ...) are now direct descendants of
the <window> element.
This fix allows selecting and clicking on an item in the toolbar, but
any drop down menus that then appear aren't clickable.
依云 [Sun, 19 Nov 2017 16:16:56 +0000 (00:16 +0800)]
support for nsPrefBranch::{get,set}StringPref() (#901)
Firefox commit:
--8<--
Bug 1414096 (attempt 2) - Remove support for nsISupportsString values in nsPrefBranch::{get,set}ComplexValue(). r=florian.
Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the
getting of utf8 strings from prefs, which previously required using
nsISupportsString with {get,set}ComplexValue. That bug also converted most
uses.
This patch finishes the job.
- It removes the nsISupportsString support.
- It converts existing code that relied on the nsISupportsString.
- It removes the lint that was set up to detect such uses of nsISupportsString.