Closed
Bug 775449
Opened 12 years ago
Closed 8 years ago
Implement scroll indicators for asynchronously-panned/zoomed content
Categories
(Core :: Graphics: Layers, defect)
Core
Graphics: Layers
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: cjones, Unassigned)
References
(Depends on 1 open bug)
Details
(Whiteboard: [tech-p1])
We're temporarily breaking these in initial landing. Only the compositor will be able to draw these, so we should probably add layers code to do this.
If that proves too difficult, we can make a gonk widget callback that draws these for the viewport frame only.
Updated•12 years ago
|
Whiteboard: blocked-on-input
Comment 1•12 years ago
|
||
Needs product/UX call.
Updated•12 years ago
|
Whiteboard: blocked-on-input → [blocked-on-input Josh Carpenter]
Comment 2•12 years ago
|
||
Can someone explain where we'll see "scroll indicators for asynchronously-panned/zoomed content"? Presumably web-browser content? Would this issue only come up when the content is zoomed?
Reporter | ||
Comment 3•12 years ago
|
||
For v1, just "browser tabs", yes. There's no indicator currently for them.
Comment 4•12 years ago
|
||
If this was any other app, I'd be less inclined to say Basecamp-blocker, but stakeholders inside and outside Moz have made clear this is a flagship app. I think we need to solve for it. But I defer to Product and Eng, who each have better 10,000 ft view of current priority stack.
Updated•12 years ago
|
Whiteboard: [blocked-on-input Josh Carpenter]
Comment 5•12 years ago
|
||
I think we can live without this for v1. I rather have a ship on time than a flag ship in the indefinite future.
Comment 6•12 years ago
|
||
+ Chris Lee for input.
Comment 7•12 years ago
|
||
Just so I'm clear, this is just the indicator of where the user is when they are zoomed and panning?
The functionality of zooming and panning are unaffected?
Agree, I would not block on this. But let's be clear that the browser *must* be our best, most polished application.
Reporter | ||
Comment 8•12 years ago
|
||
(In reply to Chris Lee [:clee] from comment #7)
> Just so I'm clear, this is just the indicator of where the user is when they
> are zoomed and panning?
>
> The functionality of zooming and panning are unaffected?
>
That's correct.
Comment 9•12 years ago
|
||
Based on comments 5, 7, and 8, let's not block basecamp here.
blocking-basecamp: ? → -
Comment 10•12 years ago
|
||
Sorry to be pedantic, but just to confirm: even if we don't fix this, the panning-scrollbars will still be available when the content is _not_ zoomed in, correct? It's only upon zoom that we'll lose them?
Reporter | ||
Comment 11•12 years ago
|
||
No: without this work, there will never be scroll indicators in "browser tabs".
Comment 12•12 years ago
|
||
> No: without this work, there will never be scroll indicators in "browser tabs".
Ah ha. Ok. Chris Lee, does that change your perspective on blocking status? Just want to make sure there's clarity. I wasn't sure whether this applied to "Zoomed _&_ Panned" or "Zoomed _or_ Panned". Sounds like later is the case, and this bug prevents scrollbars completely, no matter what state the content is in.
Reporter | ||
Updated•12 years ago
|
Blocks: b2g-v-next
Comment 14•8 years ago
|
||
B2G did eventually get scrollbars.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•