dozens of Subframes when using multiple linux workspaces

chrisamow commented 7 years ago

Mint18, mate - 4 workspaces (most of my other computers just have single workspace and I've never seen this behavior. When looking at the google-chrome taskmanager, Extension: Vimium has a huge block of Subframe: Vimium entries listed (seems like about 1 entry per chrome window opened - and closing a window shrunk the list)

Only a minor inconvenience (makes using task manager cumbersome) - don't see other effects, unless that is the cause of the chrome sluggishness I've been seeing.

Chrome: Version 56.0.2924.87 (64-bit)

danielyli commented 7 years ago

This happens on macOS as well. Numerous subframes when I have multiple tabs open.

MacOS 10.12.3, Chrome 56.0.2924.87 (64-bit), 1.57

wocala commented 7 years ago

+1. what's going on? Windows 10 Chrome 57.0.2987.98 (Official Build) (64-bit)

scottyschup commented 7 years ago

+1 Same here. Chrome 57.0.2987.133 (64-bit) MacOS X Yosemite 10.10.5 (14F2109) Vimium 1.59

screen shot 2017-04-17 at 11 18 33 am

mrmr1993 commented 7 years ago

This is causally related to #1838. We use <iframe>s to provide the Vomnibar (PR #1390) and the HUD (PR #1401), which we load in every tab. (Note that the help dialog is also an <iframe>, but we don't preload it).

Justifications for this include:

insulating the Vomnibar from the page, so the page can't abuse its privileged access
keep the HUD separate from the page, so they can have independent selection contexts
- this lets us search while typing, creating a selection in the page and having a cursor in the HUD
- this also enabled us to copy, paste, and generally use the HUD as a genuine input, instead of a "letter stack", as it was previously implemented.
without preloading, the corresponding input isn't ready to respond to the user typing
- for example, someone fluently typing /test<Enter> to search for "test" may have letters missing from the searchbox

philc / vimium

dozens of Subframes when using multiple linux workspaces #2434