aboutsummaryrefslogtreecommitdiffstats
path: root/content_scripts/ui_component.coffee
AgeCommit message (Collapse)Author
2015-09-21Add a comment explaining the choice of XMLHttpRequest for UIComponentmrmr1993
2015-09-19Tidy up #1833.Stephen Blott
2015-09-18Load UIComponent stylesheet via XMLHttpRequest, use background as neededmrmr1993
2015-09-13Don't show UIComponent <iframe>s while vimium.css loadsmrmr1993
This fixes #1817, where our stylesheet isn't loaded correctly due to a Chromium issue and the Vomnibar/HUD <iframe>s are always visible on the new tab page.
2015-08-28clean codegdh1995
2015-08-26Use createElementNS for XML documents and remove XML specific codepathsmrmr1993
This implements @gdh1995's idea from #1796.
2015-05-29Also disable all externally-used functions for XML.Stephen Blott
2015-05-29Disable UIComponent for XML documentsmrmr1993
If the page is an XML document, nothing we do works: * <style> elements show their contents inline, * <iframe> elements don't load any content, * document.createElement generates elements that - have Element.style == null, and - ignore CSS. This commit stops us from injecting anything into the DOM from UIComponent, fixing #1640.
2015-05-26Refactor to avoid potential race condition (cont).Stephen Blott
2015-05-26Refactor to avoid potential race condition.Stephen Blott
I haven't seen this happen, but... It could be possible for the iframe's contents to load before this callback is called (on nextTick), in which case the "load" callback wouldn't be called. So we delay setting the iframe's source until nextTick has elapsed.
2015-05-26Add comment noting why we need AsyncDataFetcher.Stephen Blott
2015-05-25Fix UI Component race condition on start up.Stephen Blott
Approach: Re-use the existing AsynDataFetcher class to "fetch" and use the iframe message port. Messages are queued until the iframe's contents have loaded and the message port is open. Fixes #1679.
2015-05-18Fix vomnibar stuck open.Stephen Blott
See #1671. The problem was that we were making the vomnibar visible in the frontend, even if the vomnibar initialisation was not yet complete, and the iframe port was not yet available. (Also, @activate() is never being called without options, so we can drop that test.) Fixes #1671.
2015-05-13Move the HUD to an iframe, managed by UIComponentmrmr1993
2015-05-11Use css @import rather than XMLHttpRequest for shadow DOM external stylemrmr1993
2015-05-01Rename UIComponent class to match the one used in the stylesheetmrmr1993
2015-04-28Load stylesheet via XHR to fix styles in UIComponent Shadow DOMmrmr1993
Shadow DOM doesn't support <link>s, so we have to load the stylesheet manually and inject it into a <style> element.
2015-04-28Load the Vomnibar (and all UIComponents) in a shadow DOMmrmr1993
This insulates them from page CSS, so we don't have to compete to style elements correctly.
2015-04-28Fix vomnibar start-up messages.Stephen Blott
2015-04-26Disable frame flash after Vomnibar closes.Stephen Blott
The UX around this is not quite right yet. It's better to disable it for now.
2015-04-26Remove (overlooked) debugging code.Stephen Blott
2015-04-23Activate vomnibar in window.top; no flicker and tidy up.Stephen Blott
1. Rework event handling to eliminate frame flicker (a la #1485). 2. Tidy up logic. Which should make this more robust.
2015-03-17Activate vomnibar in window.top; more clean up.Stephen Blott
Clean up, and fixes following code review from @mrmr1993.
2015-03-17Activate vomnibar in window.top; fix race condition on close.Stephen Blott
2015-03-17Activate vomnibar in window.top; more clean up.Stephen Blott
2015-03-17Activate vomnibar in window.top; hide on focus, fixed.Stephen Blott
2015-03-17Activate vomnibar in window.top; hide on focus.Stephen Blott
2015-03-17Activate vomnibar in window.top; simplify messaging.Stephen Blott
2015-03-17Activate vomnibar in window.top; refocus original frame.Stephen Blott
2015-03-16Activate vomnibar in window.top.Stephen Blott
This changes vomnibar commands to activate not in the current frame, but in window.top. Consequently, the vomnibar always appears in the same position, and we don't get odd looking vomnibars in small frames. Apart from the better UX, this seems to be the right thing to do. Vomnibar commands apply to tabs (not frames). Currently incomplete: - On exit, the focus is not returned to the frame which originally had the focus. (It's returned to window.top). - The vomnibar can lose the focus and not hide itself for various frame/click combinations.
2015-03-06Correctly remove event listeners.Stephen Blott
Fix oversight from #1517.
2015-03-05Hide vomnibar if host frame regains focus.Stephen Blott
Fixes #1506. This takes the opposite approach to #1511. Instead of hiding the vomnibar when it blurs, we hide it when it's host frame is focused.
2014-12-30Use classes and a stylesheet for UIComponenmrmr1993
2014-12-30Reinstate UIComponent.showmrmr1993
2014-12-29Use UIComponent for Vomnibar iframemrmr1993
2014-12-29Clearer handling of @showing in UI component.Stephen Blott
2014-12-29Refactor UIComponent, etc., and demo.Stephen Blott
- Simplify component API. - Iframe flashes on re-focus. - Probably some other stuff which I've forgotten.
2014-12-29Add UIComponent.active, so we can specify whether to focus the framemrmr1993
2014-12-29Remove key handling in UIComponentServer/UIComponent codemrmr1993
2014-12-29Allow message passing directly from UIComponent.showmrmr1993
2014-12-29Small changes to UIComponentmrmr1993
2014-12-29Initialise hide/show styles for UIComponentmrmr1993
2014-12-29Close UIComponent iframes when pressing esc by defaultmrmr1993
2014-12-28Add UIComponent code for iframesmrmr1993
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-08 05:29:38 +0000