Closed Bug 775449 Opened 12 years ago Closed 8 years ago

Implement scroll indicators for asynchronously-panned/zoomed content

Categories

(Core :: Graphics: Layers, defect)

Product:
Core
Component:
Graphics: Layers
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Project Flags:
blocking-kilimanjaro ?
blocking-basecamp -

People

(Reporter: cjones, Unassigned)

References

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.
Whiteboard: blocked-on-input
Needs product/UX call.
Whiteboard: blocked-on-input → [blocked-on-input Josh Carpenter]
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?
For v1, just "browser tabs", yes. There's no indicator currently for them.
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.
Whiteboard: [blocked-on-input Josh Carpenter]
I think we can live without this for v1. I rather have a ship on time than a flag ship in the indefinite future.
+ Chris Lee for input.
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.
(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.
Based on comments 5, 7, and 8, let's not block basecamp here.
blocking-basecamp: ? → -
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?
No: without this work, there will never be scroll indicators in "browser tabs".
> 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.
Needed for competitive parity.
Whiteboard: [tech-p1]
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.