* fix: restore parts of original ResourceRequestBody V8 conversion
Restore some of the original conversion logic in order to fix target=_blank post form submissions.
* test: add test for POST form submission
* fix: correctly set cookie date
* fix: name is not required for setting cookie
* test: clear cookie after each cookie test
* test: should test session property
* chore: style fixes
Electron's `AtomNSWindow` implements `accessibilityAttributeValue` to
provide various accessibility info to the OS, including window titles.
Chromium 75 changed to Apple's newer accessibility API for window titles
in the super class that `AtomNSWindow` inherits from. macOS still
supports both the old and new style APIs, but it will prefer the new
style if it is implemented. This means the Electron window title is
being ignored because the newer API at the Chromium level has taken
precedence.
By implementing the newer accessibility API in `AtomNSWindow`, this
restores correct accessibility window titles in macOS Electron apps.
This is a regression has been present since Electron 6.0.0 (the first
release including the Chromium change above).
In #20829, we fixed compositor recycling when switching between
BrowserViews, but it turns out that there is one additional case that we
need to handle. When we create a completely new BrowserView instance, it
starts of as visible (even when it hasn't been added to the window),
which means that it will need its own compositor instead of using the
recycled compositor.
To fix this, lets make BrowserViews hidden by default until they're
added to the window. See also #19988. This is a potentially breaking
change given that the initial value of `document.visibilityState` will
now be `hidden`, but given the experimental status of BrowserViews, I
think this is a fine change to make. The old behavior can be restored
with `webPreferences: { show: true }`.
Notes: Fix compositor recycling when creating new BrowserView
* fix: menu visibility should not be overwritten on startup
* fix: removing menu for window without global menubar
* test: setMenu tests are not for mac
* test: update DOM storage quota limits test
* fix: update dom_storage_limits.patch (fixes#13465)
The previous version of this patch did not include
changes required to circumvent the quota enforcement
performed by StorageAreaImpl. Consequently when
the quota was exceeded, things still "appeared to
work" at first but then would later fail silently.
That is, the cache would be updated but the backing
store would not.
This could be fixed by disabling the code below
(from `content/browser/dom_storage/storage_area_impl.cc`)
```
// Only check quota if the size is increasing, this allows
// shrinking changes to pre-existing maps that are over budget.
if (new_item_size > old_item_size && new_storage_used > max_size_) {
if (map_state_ == MapState::LOADED_KEYS_ONLY) {
receivers_.ReportBadMessage(
"The quota in browser cannot exceed when there is only one "
"renderer.");
} else {
std::move(callback).Run(false);
}
return;
}
```
However, since this seems to have some unintended side-effects
(see updated notes in dom_storage_limits.patch) it seems
more prudent to simply increase the quota to a larger
yet still reasonable size rather than attempt to circumvent
the storage quota altogether.
