Custom CSS not applied to new pages

[dawsdep]

I have some custom CSS set (which is a much appreciated feature) but there are times when the default styles are still applied until I reload the page.

Steps to reproduce the behavior (90% consistent):

1. Press 't' to open a new tab
2. Type in a search and hit enter
3. Press 'f' for link hints

Since it only seems to happen on a new page and not every single time, maybe there's something happening while things are loading or initializing?

With custom CSS:

Custom CSS not being applied:

Chrome: 79.0.3945.88
Vimium: 1.64.6
macOS: 10.15.2

[gdh1995]

Seems a duplicate of #3418 and would be worked around by #3421.

[dawsdep]

I saw that issue but thought this might be different since it's not involving iframes? I'm happy to close this if it's the same thing.

[gdh1995]

If I remembered it correctly, when I tested the old issue I also reproduced it on single-frame pages, and the PR does not deal with iframes differently.

Update: maybe I need to do more tests, so I'll investigate more in days.

Update 2: in fact #3732 works in most time, except the short time before a web page gets completely downloaded (content-loaded) from Internet.

[travankor]

I run into this issue, too.

[parogen]

Still running into this issue

[He4eT]

I regularly encounter this problem too :c

[duckyb]

@gdh1995 adding onto this issue;

I think the style for the background of the searched text is broken, i tried both color and background-color and nothing changed.

[sebastian-65]

Custom CSS seems to be ignored completely in my case (Vivaldi 3.3, Xubuntu 16.04.3).

Since there are troubles with custom CSS, is it possible to somehow replace / overwrite the default one?

[0x462e41]

I'm experiencing the same issue, and it's really annoying to have to reload each new tab to temporarily fix it. Has anyone found a way to make it work and always load the custom CSS instead of the default one? Thanks

[0x462e41]

I found a workaround. As @sebastian-65 thought, by overwriting the default configuration I managed to fix it. It's not ideal, but get the job done for now.

In the file "$XDG_CONFIG_HOME/chromium/Default/Extensions/<id_number>/<version_number>/content_scripts/vimium.css" I changed the attributes of "div.internalVimiumHintMarker", "div.internalVimiumHintMarker span" and "div.internalVimiumInputHint" to match my custom CSS "hint" configuration. Even though I have lots of stuff in my custom CSS, the issue only affects the hint, so that was all I had to change.

Hope this helps someone.

[sebastian-65]

I'm glad to hear you've made it @0x462e41!

I'm definitely gonna try it in couple of days. Thank you for your investigation!

[mcp292]

Pretty cool link hints. Consider sharing the CSS on the theme page.

[f-viktor]

I found a workaround. As @sebastian-65 thought, by overwriting the default configuration I managed to fix it. It's not ideal, but get the job done for now.

In the file "$XDG_CONFIG_HOME/chromium/Default/Extensions/<id_number>/<version_number>/content_scripts/vimium.css" I changed the attributes of "div.internalVimiumHintMarker", "div.internalVimiumHintMarker span" and "div.internalVimiumInputHint" to match my custom CSS "hint" configuration. Even though I have lots of stuff in my custom CSS, the issue only affects the hint, so that was all I had to change.

Hope this helps someone.

this no longer works, as chromium now checks for modifications of plugins, and disables them if they no longer match their expected hash. :(

[BachoSeven]

this no longer works, as chromium now checks for modifications of plugins, and disables them if they no longer match their expected hash. :(

I mean, you can just download the source from github and load it as an unpacked extension from chrome://extensions in developer mode, so there is no hash verification and you can just edit the source as you wish.

[itajsh]

Added the following code in main.js, and it seems to fix the problem. That is, the CSS from the settings is applied.
Just found some examples online. It's first time that I write chrome extension code, so consider it experimental.

For me this bug happened a lot when using activateModeToOpenInNewForegroundTab.
As a dark mode user, it is extremely annoying.

// This is already in main.js:

chrome.webNavigation.onCommitted.addListener(function({tabId, frameId}) {
  const cssConf = {
    frameId,
    code: Settings.get("userDefinedLinkHintCss"),
    runAt: "document_start"
  };
  return chrome.tabs.insertCSS(tabId, cssConf, () => chrome.runtime.lastError);
});

// I added this:

chrome.tabs.onCreated.addListener(insertCssForTab);
chrome.tabs.onUpdated.addListener(function(tabId, info, tab) {
  if (info.status == 'complete') {
    insertCssForTab(tab);
  }
});

function insertCssForTab(tab) {
  const tabId = tab.id;
  const cssConf = {
    allFrames: true,
    code: Settings.get("userDefinedLinkHintCss"),
    runAt: "document_start"
  };
  chrome.tabs.insertCSS(tabId, cssConf, () => chrome.runtime.lastError);
}

[gdh1995]

@itajsh runAt supports document_end, so it's not needed to wait for onUpdated(status: complete). So, you may call insertCSS in onCommitted twice and the second one should be like https://github.com/philc/vimium/pull/3421/files.

[itajsh]

@gdh1995 OK, this seems to work too.
Could something like that be done in Vimium master?

[philc]

This should now be fixed in Vimium on master (v2.0); see discussion in #3883. If you find you're still able to reproduce this with Vimium v2.0, please post detailed instructions to reproduce.