Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

zoom always displays 100% on hamburger menu #14045

Closed
LaurenWags opened this issue May 7, 2018 · 4 comments
Closed

zoom always displays 100% on hamburger menu #14045

LaurenWags opened this issue May 7, 2018 · 4 comments

Comments

@LaurenWags
Copy link
Member

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

  1. Open a site.
  2. Zoom in or out (via shortcut or hamburger menu.

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

@LaurenWags LaurenWags added bug regression 0.22.x-single-webview Issue first seen on single-webview build against v0.22.x branch labels May 7, 2018
@LaurenWags LaurenWags added this to the 0.22.x Release 3 (Beta channel) milestone May 7, 2018
@petemill
Copy link
Member

petemill commented May 8, 2018

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.
@petemill petemill closed this as completed May 8, 2018
@btlechowski
Copy link
Contributor

Still reproducible.

Brave: 0.22.703 
V8: 6.6.346.26 
rev: 903b8d0d3703b5fdc5a719294403e7460d9b806d 
Muon: 6.0.8 
OS Release: 4.13.0-21-generic 
Update Channel: Beta 
OS Architecture: x64 
OS Platform: Linux 
Node.js: 7.9.0 
Brave Sync: v1.4.2 
libchromiumcontent: 66.0.3359.139

@btlechowski btlechowski reopened this May 8, 2018
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
Copy link
Member

petemill commented May 9, 2018

Should be fixed (again) in next build via f4c5b68. Windows and Linux do not emit the preffered-size-changed event, and there is no other event for when a Tab's zoom is changed. Still one minor regression which can be fixed by implementing a zoom-changed event in muon and reported at #14070

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.
@LaurenWags
Copy link
Member Author

LaurenWags commented May 10, 2018

Verified with macOS 10.12.6 using

  • 0.22.706 e11b027
  • muon 6.0.9
  • libchromiumcontent 66.0.3359.139

Verified on Windows x64

  • 0.22.706 e11b027
  • libchromiumcontent 66.0.3359.139
  • muon: 6.0.9

Verified on Ubuntu 17.10 x64

  • 0.22.706 e11b027
  • libchromiumcontent 66.0.3359.139
  • muon: 6.0.9

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.
Projects
None yet
Development

No branches or pull requests

4 participants