Closed
Bug 933556
Opened 11 years ago
Closed 11 years ago
Really odd zoom behavior on bing images
Categories
(Core :: Panning and Zooming, defect)
Tracking
()
RESOLVED
FIXED
mozilla28
People
(Reporter: jimm, Assigned: cwiiis)
References
Details
(Whiteboard: [release28])
Attachments
(1 file)
(deleted),
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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.
Updated•11 years ago
|
Whiteboard: [triage] → [block28]
Comment 1•11 years ago
|
||
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)
Comment 2•11 years ago
|
||
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
Comment 3•11 years ago
|
||
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•11 years ago
|
||
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]
Assignee | ||
Comment 5•11 years ago
|
||
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)
Assignee | ||
Comment 6•11 years ago
|
||
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.
Attachment #831546 -
Flags: review?(roc) → review+
Assignee | ||
Comment 7•11 years ago
|
||
Pushed to b2g-inbound:
https://hg.mozilla.org/integration/b2g-inbound/rev/9ca652b304c0
Comment 8•11 years ago
|
||
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.
Description
•