933556 - Really odd zoom behavior on bing images

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Jim Mathies [:jimm]]

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.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 2

[Matt Brubeck (:mbrubeck)]

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.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 5

[Chris Lord [:cwiiis]]

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).

Comment 6

[Chris Lord [:cwiiis]]

Attachment: Anchor fixed, left+right/top+bottom positioned content to center

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.

Comment 7

[Chris Lord [:cwiiis]]

Pushed to b2g-inbound:

https://hg.mozilla.org/integration/b2g-inbound/rev/9ca652b304c0

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9ca652b304c0