| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Remaining following 290f5877b95585e73c6ac1b73b11d8df39b724cd.
|
|
When a tab is closing, Chrome sometimes doesn't set sender.tab. To
reproduce, navigate (by entering the URLs directly) between www.bing.com
and www.google.com.
Fixes #1630. Partially. We still have a space leak.
|
|
When we reinject content scripts into a tab where document.body is a
frameset, no frames are registered, which causes frames to be undefined.
|
|
This reverts commit f1e46d8145c834a712f6be7c1e5bd590c72da749.
|
|
smblott-github/fix-grab-back-focus-after-web-navigation
Fix grab back focus after web navigation
|
|
|
|
|
|
|
|
Fixes #1585.
|
|
- Simplify the settings logic.
- Send a single request for all required settings (instead of 12
inidividual requests for the 12 settings values we need in the front
end).
|
|
|
|
We track the URL of the active frame in each tab so that we can
correctly populate the rules in the page popup.
Previously, we tracked URL changes only on focus events. This commit
moves that to isEnabledForURL, which is also called when the URL changes
as a result of web navigation.
|
|
|
|
https://github.com/mrmr1993/vimium into mrmr1993-exclusion-rules-pushState-and-hash
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
focus-main-frame-merge
Conflicts:
content_scripts/vimium_frontend.coffee
Also rework to remove dependency on Chrome 41+ sendMessage API
(specifically, relating to optional target frameId argument).
|
|
When the vomnibar closes, it focuses its enclosing window. If that is a
frameset, then we do not want to inadvertently register it.
|
|
Conflicts:
background_scripts/main.coffee
content_scripts/vimium_frontend.coffee
|
|
This uses the chrome.webRequest API to detect changes to page URL which
*do not* cause the content script to refresh.
|
|
|
|
1. Rework event handling to eliminate frame flicker (a la #1485).
2. Tidy up logic. Which should make this more robust.
|
|
This lines was never needed.
|
|
Fixes #426.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This logic should never have been in settings.coffee. This moves it to completion.coffee, where it belongs.
|
|
|
|
We're asking for the "notifications" permission. I'm not sure what
happens. If the user is asked to accept the permission, then we
wouldn't show the notification until the next time Vimium starts.
Instead, we check more frequently. So the notification will show the
next time a tab is created (or changes page).
|
|
|
|
Clean up, and fixes following code review from @mrmr1993.
|
|
|
|
|
|
|
|
|
|
Conflicts:
content_scripts/vimium_frontend.coffee
|
|
|
|
|
|
|
|
|
|
"pages/blank.html" was being sent to the default search engine by
chrome.tabs.create().
Not fully functional. New tabs created from incognito mode are created
in a non-incognito mode window.
|
|
Setting the page icon is now driven from the corrently-active frame.
- Eliminates a race condition.
- Icon matches actual frame state (not tab URL state).
- Exclusion-rule changes propagate to all frames.
|
|
When the active tab changes, we call updateActiveState to update the
icon and propagate any changed exclusion-rule state to the tab. All
frames received the request. However, only one response is received by
the background page. Therefore, new exclusion rules are only propagated
to one frame.
Here's what can go wrong...
On gmail, open the hangouts frame. Add an exclusion rule sepcific to
the hangouts frame. Save it. The update is propagated only to the main
frame. The new exclusion rule is not in effect in the hangouts frame.
That's wierd and obviously wrong.
In this commit, every frame receiving the getActiveState request also
calls checkIfEnabledForUrl to ensure that any new exclusion-rule state
is propagated. This is overkill, to some extent. We should really move
settings to chrome.storage and have each frame check locally for changes
affecting it.
|
|
Previously, we have been populating the suggested exclusion URL in the
page popup with the tab's URL. This uses the active frame's URL
instead:
- because this is the URL which will affect the current frame (without
this, a user can naively add an exclusion rule and it has no effect),
and
- because, without this, the user has no reasonable way to add exclusion
rules for frames such as the hangouts frame on gmail (for which, the
URL is not displayed in the address bar).
|
|
We should not inject content scripts on chrome upgrades.
|
