WebView.locationBarController.offset unexpectedly changes when loading a new URL
Bug #1453908 reported by
Olivier Tilloy
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | ||
|---|---|---|---|---|---|---|
| Oxide |
New
|
Undecided
|
Unassigned | |||
| webbrowser-app |
Fix Released
|
High
|
Olivier Tilloy | |||
| webbrowser-app (Ubuntu) | ||||||
| Vivid |
New
|
Undecided
|
Unassigned | |||
Bug Description
I was originally seeing this issue in webbrowser-app on my desktop (running up-to-date vivid + oxide 1.7.7), so I wrote a small standalone example that reproduces the issue (attached).
Just wait for the page to load, then click the red rectangle, and observe how the rectangle is hidden. It shouldn’t be. This is especially bad on desktop as scrolling won’t restore the top bar.
Related branches
lp://staging/~osomon/webbrowser-app/locationBarController-show-hide
- PS Jenkins bot: Needs Fixing (continuous-integration)
- Alexandre Abreu (community): Approve
-
Diff: 162 lines (+51/-46)4 files modifieddebian/control (+1/-1)
src/app/ChromeController.qml (+39/-30)
src/app/webbrowser/Browser.qml (+9/-7)
src/app/webcontainer/WebApp.qml (+2/-8)
Revision history for this message
| Olivier Tilloy (osomon) wrote | #1 |
Revision history for this message
| Olivier Tilloy (osomon) wrote | #2 |
| Changed in webbrowser-app: | |
| status: | New → In Progress |
| assignee: | nobody → Olivier Tilloy (osomon) |
| importance: | Undecided → High |
| Changed in webbrowser-app: | |
| status: | In Progress → Fix Released |
To post a comment you must log in.
From IRC discussion:
<chrisccoulson> oSoMoN, if it's on a desktop with no touch device, then mode should be set to ModeShown
<chrisccoulson> the issue you're hitting is that the state is on the renderer side, and the navigation there does a renderer swap
(and so the locationbar position is calculated from a new compositor)
<chrisccoulson> (IIUC)