As it turns out, we can reinitialize the feature list directly after the
user JS script has been executed instead of much later. This allows
modifications to `--enable-features`/`--disable-features` to work with a
greater set of features.
Implement the scrollBounce option by reading the command line flag in
`RenderThreadImpl::IsElasticOverscrollEnabled`, there is no more need
to set NSScrollViewRubberbanding.
After after using `processId-contextCounter` as contextId, it may happen
that contexts in different WebContents sharing the same renderer process
get the same contextId. Using webContentsId as part of key in
ObjectsRegistry can fix this.
* fix: create a window capturer correctly
We were incorrectly creating two screen capturers instead of a window
capturer
* spec: ensure dc tests pass
* spec: enable all tests after verifying dc tests work
Chromium commit [03563dd163][1] changed the way that the
spellcheck-enabled status was checked, defaulting to false.
Added the first (!) test for spellchecking, too.
Fixes#13608.
[1]: 03563dd163
After the page does navigations, garbage collection can still happen in
the old context. This commit changes to store references to remote objects
by _pages_, instead of by _WebContents_.
When using `views::Widget` to create window, Chromium will automatically
use a `BridgedContentView` as content view, which however does not
support draggable regions inside it.
By fallback to `FullSizeContentView` we can work around this problem,
with the price of losing the ability to use `views::View` APIs. Since
we don't expect users to use the new `View` APIs in `BrowserWindow`
anyway, it should not be a problem.
This change does not affect users of `TopLevelWindow`, and for users of
`BrowserWindow` there is nothing to lose.
In the long term we should look into how to make draggable regions work
with `BridgedContentView`. The related Chromium code is still being
changed rapidly, we can wait until Chromium migrated its
`NativeAppWindowCocoa` class to use `views::Widget`.
* fix: pass the boolean value of enableAutoSize to setSize
The webContents setSize API takes in an optional enableAutoSize boolean.
Looking in the code, if that property is set, regardless if you pass in
true or false, it will always set it to true. This change passes the
appropriate boolean value down properly.
* creating new bool for autosize
