This repository has been archived by the owner on Dec 11, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 971
zoom always displays 100% on hamburger menu #14045
Labels
0.22.x-single-webview
Issue first seen on single-webview build against v0.22.x branch
bug
QA/checked-Linux
QA/checked-macOS
QA/checked-Win64
QA/test-plan-specified
regression
release-notes/exclude
Milestone
Comments
Should be fixed in next build via 8733733 |
petemill
added a commit
that referenced
this issue
May 8, 2018
Fix #14045 Previously this was set on window state, but was not used, possibly because it was not reliable as it did not get the initial value which is set internally in muon based on origin. Instead, when this was working, it was read directly from the webview, which we try to avoid due to the webview's multi-purpose nature. For example, the webview may not be displaying the active tab - it may be displaying a preview, or waiting to display the active tab asynchronously.
petemill
added a commit
that referenced
this issue
May 8, 2018
Fix #14045 Previously this was set on window state, but was not used, possibly because it was not reliable as it did not get the initial value which is set internally in muon based on origin. Instead, when this was working, it was read directly from the webview, which we try to avoid due to the webview's multi-purpose nature. For example, the webview may not be displaying the active tab - it may be displaying a preview, or waiting to display the active tab asynchronously.
This was referenced May 8, 2018
Still reproducible.
|
petemill
added a commit
that referenced
this issue
May 8, 2018
Fix #14045 Previously this was set on window state, but was not used, possibly because it was not reliable as it did not get the initial value which is set internally in muon based on origin. Instead, when this was working, it was read directly from the webview, which we try to avoid due to the webview's multi-purpose nature. For example, the webview may not be displaying the active tab - it may be displaying a preview, or waiting to display the active tab asynchronously.
petemill
added a commit
that referenced
this issue
May 8, 2018
Fix #14045 Previously this was set on window state, but was not used, possibly because it was not reliable as it did not get the initial value which is set internally in muon based on origin. Instead, when this was working, it was read directly from the webview, which we try to avoid due to the webview's multi-purpose nature. For example, the webview may not be displaying the active tab - it may be displaying a preview, or waiting to display the active tab asynchronously. Since there is not yet a muon Tab event for 'zoom-changed', we must manually update the zoomPercent tabState property every time we knowingly change the zoom level.
petemill
added a commit
that referenced
this issue
May 9, 2018
Fix #14045 Previously this was set on window state, but was not used, possibly because it was not reliable as it did not get the initial value which is set internally in muon based on origin. Instead, when this was working, it was read directly from the webview, which we try to avoid due to the webview's multi-purpose nature. For example, the webview may not be displaying the active tab - it may be displaying a preview, or waiting to display the active tab asynchronously. Since there is not yet a muon Tab event for 'zoom-changed', we must manually update the zoomPercent tabState property every time we knowingly change the zoom level.
petemill
added a commit
that referenced
this issue
May 10, 2018
Fix #14045 Previously this was set on window state, but was not used, possibly because it was not reliable as it did not get the initial value which is set internally in muon based on origin. Instead, when this was working, it was read directly from the webview, which we try to avoid due to the webview's multi-purpose nature. For example, the webview may not be displaying the active tab - it may be displaying a preview, or waiting to display the active tab asynchronously. Since there is not yet a muon Tab event for 'zoom-changed', we must manually update the zoomPercent tabState property every time we knowingly change the zoom level.
petemill
added a commit
that referenced
this issue
May 10, 2018
Fix #14045 Previously this was set on window state, but was not used, possibly because it was not reliable as it did not get the initial value which is set internally in muon based on origin. Instead, when this was working, it was read directly from the webview, which we try to avoid due to the webview's multi-purpose nature. For example, the webview may not be displaying the active tab - it may be displaying a preview, or waiting to display the active tab asynchronously. Since there is not yet a muon Tab event for 'zoom-changed', we must manually update the zoomPercent tabState property every time we knowingly change the zoom level.
petemill
added a commit
that referenced
this issue
May 10, 2018
Fix #14045 Previously this was set on window state, but was not used, possibly because it was not reliable as it did not get the initial value which is set internally in muon based on origin. Instead, when this was working, it was read directly from the webview, which we try to avoid due to the webview's multi-purpose nature. For example, the webview may not be displaying the active tab - it may be displaying a preview, or waiting to display the active tab asynchronously. Since there is not yet a muon Tab event for 'zoom-changed', we must manually update the zoomPercent tabState property every time we knowingly change the zoom level.
This was referenced May 10, 2018
petemill
added a commit
that referenced
this issue
May 11, 2018
Fix #14045 Previously this was set on window state, but was not used, possibly because it was not reliable as it did not get the initial value which is set internally in muon based on origin. Instead, when this was working, it was read directly from the webview, which we try to avoid due to the webview's multi-purpose nature. For example, the webview may not be displaying the active tab - it may be displaying a preview, or waiting to display the active tab asynchronously. Since there is not yet a muon Tab event for 'zoom-changed', we must manually update the zoomPercent tabState property every time we knowingly change the zoom level.
petemill
added a commit
that referenced
this issue
May 11, 2018
Fix #14045 Previously this was set on window state, but was not used, possibly because it was not reliable as it did not get the initial value which is set internally in muon based on origin. Instead, when this was working, it was read directly from the webview, which we try to avoid due to the webview's multi-purpose nature. For example, the webview may not be displaying the active tab - it may be displaying a preview, or waiting to display the active tab asynchronously. Since there is not yet a muon Tab event for 'zoom-changed', we must manually update the zoomPercent tabState property every time we knowingly change the zoom level.
petemill
added a commit
that referenced
this issue
May 11, 2018
Fix #14045 Previously this was set on window state, but was not used, possibly because it was not reliable as it did not get the initial value which is set internally in muon based on origin. Instead, when this was working, it was read directly from the webview, which we try to avoid due to the webview's multi-purpose nature. For example, the webview may not be displaying the active tab - it may be displaying a preview, or waiting to display the active tab asynchronously. Since there is not yet a muon Tab event for 'zoom-changed', we must manually update the zoomPercent tabState property every time we knowingly change the zoom level.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
0.22.x-single-webview
Issue first seen on single-webview build against v0.22.x branch
bug
QA/checked-Linux
QA/checked-macOS
QA/checked-Win64
QA/test-plan-specified
regression
release-notes/exclude
Description
When you zoom either via shortcut or hamburger menu, the value displayed on the hamburger menu should reflect your zoom level. With 0.22.702 it always says 100% even after zooming.
Steps to Reproduce
Actual result:
Value displayed on hamburger menu is not indicative of your zoom level, it just displays 100%.
Expected result:
Zoom displayed on hamburger menu should reflect your zoom level.
Reproduces how often:
Easily
Brave Version
about:brave info:
0.22.702
Reproducible on current live release:
no, does not reproduce on 0.22.702
Additional Information
Reproduced on macOS by @kjozwiak and Linux by @btlechowski
The text was updated successfully, but these errors were encountered: