aboutsummaryrefslogtreecommitdiffstats
path: root/content_scripts
AgeCommit message (Collapse)Author
2016-04-23Fix help dialog HTML.Stephen Blott
- Style the links at the top the same as those at the bottom (re. colour). - Fix HTML indentation.
2016-04-22Nicer styling of command names in help dialog.Stephen Blott
The commands names (in the help dialog) look nicer in italics. They also format better that way.
2016-04-22Better help-dialog formatting.Stephen Blott
Use margins to centre the help dialog. This works better on narrow windows, and seems to produce a balanced dialog in a variety of cases.
2016-04-22Fix x-axis position.Stephen Blott
This gest the centring calculation correct. Also, remove the shadow; it's not visible.
2016-04-22Help dialog; do not offer hints outside of the help dialog.Stephen Blott
2016-04-22Help dialog; better formatting of command names.Stephen Blott
This needs more work.
2016-04-22Help dialog; set maximum width.Stephen Blott
2016-04-22Help dialog: put keys in greyed-out box.Stephen Blott
2016-04-22Help dialog: increase size and make white background.Stephen Blott
2016-04-22Place help dialog in darkend frame.Stephen Blott
This mimics the look of Google Inbox or Github. The background colour is from Google Inbox, Github uses a slightly lighter colour.
2016-04-22Simplify 618d66bbd57d7709f211149305ebc41f1b6941f9.Stephen Blott
2016-04-21Prime focus input on the Vimium options page.Stephen Blott
This is a bit of a hack, and pertains to focusInput (`gf`). The problem... On the options page, there are *lots* of inputs (specifically, for every exclusion rule there are two inputs). This makes `gf` almost unusable. It's impossibly to `Tab` through them all. Here, on the options page, we prime the pre-selected input to be the key-mappings input: - arguably, this is the most frequently used input, and - other inputs (such as custom search engines) are just one `Tab` away.
2016-04-21Reinstate Vomnibar init on load.Stephen Blott
This effectively reverts 4b564e8517dd3415cb8e2209ce019fa024e88770. Reinstate pre-initialization of the Vomnibar. Without pre-initialization, there is a small but noticable sluggishness the first time the Vomnibar is opened.
2016-04-21Help dialog; remove ability to blur the dialog.Stephen Blott
Previously, you could blur the help dialog on the options page (to read and type command names). With the reinstated help-dialog styling (whereby the help-dialog iframe extends across the entire window), this doesn't make sense. So it's removed.
2016-04-21Revert "Rework the help dialog styling."Stephen Blott
This reverts commit 86470f13d853b33cda8cb006ae24aeb2dcec0c9c.
2016-04-21Revert "Reinstate help dialog shadow."Stephen Blott
This reverts commit d95f811a8bc32803bfaec69e4853c5d48500905e.
2016-04-18Reinstate help dialog shadow.Stephen Blott
2016-04-18Rework the help dialog styling.Stephen Blott
We make the help dialog iframe cover most of the height of the window, but only be as wide as it needs to be. Like this, the user can click to the side of the dialog (on the options page) to enter bindings in the custom ley mapping input, with the help dialog open.
2016-04-18Tweak max height of help dialog.Stephen Blott
Apart from looking better (ie. symmetric), this also ensures that the help dialog does not overlap the footer on the options page (which is ugly).
2016-04-18Revert "Fix options page when help-dialog showing."Stephen Blott
This reverts commit f0911e52f0e71c6d2539bdc74a09ff2dbd5ab125. Conflicts: content_scripts/vimium.css Revert previous change to help-dialog styling.
2016-04-18Cache content_scripts/vimium.css in chrome.storage.local.Stephen Blott
Previously, we had two different approaches. This seems like a simpler approach. We simply cache the Vimium CSS in chrome.storage.local (in the background page) and fetch it from there (in UI components). There is also a minor change in the we no longer cache the CSS in memory. This seems to be the right thing to do. Caching the CSS in memory consumes a small amount of memory. However, it can only speed up the fastest loads. It cannot speed up the first load -- which is likely the one that matters most. So caching the CSS in memory seems to make little sense.
2016-04-18Revert "Cache content_scripts/vimium.css in chrome.storage.local."Stephen Blott
This reverts commit 0a49cc45732175c65651b5f054c677d6c42a28c0.
2016-04-18Cache content_scripts/vimium.css in chrome.storage.local.Stephen Blott
Previously, we had two different approaches. This seems like a simpler approach. We simply cache the Vimium CSS in chrome.storage.local (in the background page) and fetch it from there (in UI components). There is also a minor change in the we no longer cache the CSS in memory. This seems to be the right thing to do. Caching the CSS in memory consumes a small amount of memory. However, it can only speed up the fastest loads. It cannot speed up the first load -- which is likely the one that matters most. So caching the CSS in memory seems to make little sense.
2016-04-18Simplify find-mode exit event.Stephen Blott
Previously, we were transferring a "transferable event" from the HUD UI component to the content script (when find mode exits). In addition to being unnecessary, this was triggering a warning in the console because we were reading *all* of the events keys, including one which triggers a "this is being deprecated" warning. The approach here is simpler, transfers less data and avoids triggering the warning.
2016-04-18Abandon HUD on help-dialog close.Stephen Blott
If the help dialog loses the focus and closes, then we abandon any HUD which is being displayed. This ensures that - when the help dialog is reopenned - we're not displaying an old, out-of-date HUD message.
2016-04-18Wait for documentReady() when whoeing ui components.Stephen Blott
Previously, requests (like opening the Vomnibar) would be silently discarded if they arrive before the document is ready. Here, we queue them instead.
2016-04-18Require documentReady for all UI components.Stephen Blott
This replaces c01d7eea8675f9a7d84999777e8de72244d687b6. All UI components require the document to be ready. So, here the constructor waits for DomUtils.documentReady(). The diff looks big, but mainly it's a result of changes in indentation in the constructor and in hide(). Also, hide() now uses @postMessage() to post a null message. This forces hide to use @iframePort.use(), which ensures that hide()s cannot overtake activate()s. This continues #2100.
2016-04-18Revert "UI-compnent commands must wait for the document to be ready."Stephen Blott
This reverts commit c01d7eea8675f9a7d84999777e8de72244d687b6. Preparatory to implementing an alternative approach.
2016-04-17UI-compnent commands must wait for the document to be ready.Stephen Blott
2016-04-17Only Vomnibar.init() when the Vomnibar is needed.Stephen Blott
The Vomnibar isn't needed on most tabs, so don't init it. I cannot detect any sluggishness as a result of this.
2016-04-17Do not init() the HUD until it's needed.Stephen Blott
This avoids initializing around 15 (almost all unused) HUDs on sites like GMail and Google inbox. Because the HUD is small, there is not noticable flicker.
2016-04-17Make showHelp a top-frame command.Stephen Blott
Replaces #2037.
2016-04-17Make showHelp not a background command.Stephen Blott
2016-04-17Fix 5c3e4bda2968486e23f8cc3410e776de67fec849.Stephen Blott
In 5c3e4bda2968486e23f8cc3410e776de67fec849, I omitted to observe that we need to know whether the window has the focus *before* the DOM is ready when checking whether Vimium is enabled. This fixes that.
2016-04-17Better window focus handling.Stephen Blott
This fixes two issues: - We cannot set windowHasFocus until the DOM is ready (because document.hasFocus isn't set until then. - We should use windowhasFocus in prefernce to document.hasFocus because, for framesets, document.hasFocus is true for both the frameset and a focused contained frame.
2016-04-17More code review of UI-component focus handling.Stephen Blott
2016-04-17Use register/unregister frame in help dialog.Stephen Blott
Remove special-purpose code from `gf`. Instead, register the help dialog frame when it launches, and unregister it when it's hidden. This way, when the helpd-dialog frame is hidden, it simply isn't available for `gf` and for link hints.
2016-04-16Minor code review.Stephen Blott
2016-04-16Do not focus a hidden help dialog.Stephen Blott
When the help dialog UI component has been created but subsequently hidden, `gf` was nevertheless selecting it.
2016-04-16Reinstate vomnibar from within help dialog.Stephen Blott
2016-04-16Self code review re. ui-component focus handling.Stephen Blott
2016-04-16We cannot wait for nextTick() here...Stephen Blott
It interferes with the HUD's timing.
2016-04-16Remove dead code from the HUD initialization.Stephen Blott
2016-04-16Rework UI component focus handling.Stephen Blott
The code to handle the focus for UI components has been tweaked and adapted over time, and has become quite complicated (and brittle). This reworks it from scratch, and co-locates similar code which does related things. Fixes #2099.
2016-04-14Merge pull request #2097 from smblott-github/ui-component-init-sequenceStephen Blott
Rework UI component init sequence.
2016-04-14Rework UI component init sequence.Stephen Blott
In testing global link hints, it seems that UI components can be opened before they're actually ready, and Vimium hangs with a broken UI component displayed. This issue seems to be in 1.54 too. It's not clear what's causing this -- and it's hard to reproduce systematically. However, it only seems to happen on navigation. Therefore, it seems likely that there is an issue with the initialization sequence. Here, we wait for: - the DOM content to be ready, and - the port to be provided before registering the UI component as ready.
2016-04-13Add <c-y> and <c-e> for visual mode.Stephen Blott
Fixes #2092.
2016-04-12Set the mode indicator last.Stephen Blott
Similarly to the previous commit: 454f5272c71388c53665d7505aa6832566284e2b. This is intended to mitigate some CSP violations we're seeing. In some circumstances - as yet not fully pinned down - messages to the HUD trigger CSP violations. Until we track that down, we move all HUD operations (in link hints) to the end of their execution slice. So, if HUD operations fail, then they won't affect any other operation. The error message for offending HUD operations is: ui_component.js:55: Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('chrome-extension://hiihfcebjbnoniicphblpiekhfmbdmog') does not match the recipient window's origin ('null').
2016-04-12Make rects absolute in window earlier.Stephen Blott
This is part of an effort (as yet incomplete) to track down some CSP violations we're getting, in this case related to global link hints. Prior to this, we were seeing CSP violations when accessing the window subsequently to collecting the hints, specifically when accessing window.scrollX/Y. Here, we collect the window position immediately, when initially harvesting the hints.
2016-04-11Better visual-mode selection handling.Stephen Blott
Assume there is an existing range selection. Consider `v`, `Escape`. Previously, this had the side effect of clearing the selection. That behaviour seems odd and wrong. Here, we retain the selection if there was an existing range selection when visual mode was launched. Arguably, this removes a "feature" whereby `v`, `Escape` clears the selection. Here, we take it that the oddity above outweighs the loss of this arguably unintentional "feature".
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-06 02:22:44 +0000