Closed Bug 933556 Opened 11 years ago Closed 11 years ago

Really odd zoom behavior on bing images

Categories

(Core :: Panning and Zooming, defect)

x86_64
Windows 8.1
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla28

People

(Reporter: jimm, Assigned: cwiiis)

References

Details

(Whiteboard: [release28])

Attachments

(1 file)

str: 1) search for something on bing.com ex: 'poltergeist' 2) select images 3) tap on an image thumbnail to bring up the image viewer 4) zoom the page and zoom out result: hard to describe, really weird origin issues on different layers. ie10 manages to zoom the entire page correctly at a single origin.
Whiteboard: [triage] → [block28]
Yeah this looks like a fixed-position thing. In general fixed-position elements don't play well with pinch-zoom because they are designed with fixed viewports in mind. I see the same behaviour in Fennec if I load the desktop version of bing.com. Chris, can you check out the behaviour of this page in Fennec to see if that's expected or can be improved? STR on release Fennec: 1. Go to bing.com 2. "Request desktop site" from the menu 3. Follow steps in comment 0 If there's nothing we can improve on our end we should try to get Bing to serve us the tablet version by default which shouldn't have this problem. We can move this bug to tech evangelism if that's the case.
Flags: needinfo?(chrislord.net)
I think this is a case of bug 656036. As far as I know, IE10+ is the only browser that handles cases like this well. IE10 ended up implementing the behavior that I suggested in bug 607417 comment 5, but no other mobile browser has.
Depends on: 656036
It would be interesting to talk to the IE guys to see if they've run into problematic scenarios with that implementation, or if feedback from web devs has been positive/negative.
Also I'm going to drop this down to release28 since it's unlikely we can solve this problem in the next couple of weeks.
Whiteboard: [block28] → [release28]
This is basically expected, but I think we could be slightly nicer - because the element in question has top, right, bottom and left properties, it ends up triggering all of the alignment paths and the ones that come last (bottom, right) take precedence. I think we should check if both are specified and align to the middle in that case That behaviour would look much nicer in this case. I'm going to see if I can quickly prototype a patch that does this. On the other hand, we can never have something that feels *completely* natural in this case I don't think (unless we do what mbrubeck suggests in the comment he mentions in comment #2).
Flags: needinfo?(chrislord.net)
This looks and feels *much* nicer to me. It's not perfect by any means, but it's certainly a lot nicer than what we're currently doing.
Assignee: nobody → chrislord.net
Status: NEW → ASSIGNED
Attachment #831546 - Flags: review?(roc)
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: