| Age | Commit message (Collapse) | Author |
|---|
|
In the previous commits, I omitted to actually check that the help
dialog wasn't closing on the options page.
I should be good now.
|
|
The help-dialog UI component was ignoring requests to "hide" when other
frames are focused (because previously it covered the whole screen, and
no other frame could get the focus).
With f0911e52f0e71c6d2539bdc74a09ff2dbd5ab125, the help dialog no longer
covers the whole screen, so it must listen for and react to
"frameFocused" events.
However, the help dialog should not "hide" when the frame that is
focused is itself! This required a little extra plumbing. That
plumbing is helpful, though, because it allows individual UI components
to decide what to do when another frame receives the focus (as opposed
to the previious version, which simply unilaterally sent a "hide"
message).
|
|
Problem:
- `?`, `o`, `Esc`, `Esc` leaves the focus in the (invisible) help dialog
frame, rendering Vimium broken.
Since we do
@iframeElement.focus()
when we activate a UI component, here we do
@iframeElement.blur()
when hiding such elements.
Fixes #2038.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
This implements @gdh1995's idea from #1796.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
Shadow DOM doesn't support <link>s, so we have to load the stylesheet
manually and inject it into a <style> element.
|
|
This insulates them from page CSS, so we don't have to compete to style
elements correctly.
|
|
|
|
The UX around this is not quite right yet. It's better to disable it
for now.
|
|
|
|
1. Rework event handling to eliminate frame flicker (a la #1485).
2. Tidy up logic. Which should make this more robust.
|
|
Clean up, and fixes following code review from @mrmr1993.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Fix oversight from #1517.
|
|
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.
|
|
|
|
|
|
|
|
|
|
- Simplify component API.
- Iframe flashes on re-focus.
- Probably some other stuff which I've forgotten.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
