Bug 10290 - (int-171321) Can't zoom to posts column on Talk
(int-171321)
: Can't zoom to posts column on Talk
Status: RESOLVED FIXED
Product: Browser
Zooming
: 5.0:(10.2010.19-1)
: All Maemo
: Unspecified minor with 2 votes (vote)
: 5.0/(20.2010.36-2)
Assigned To: unassigned
: browser-zooming-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2010-05-26 06:58 UTC by Ryan Abel
Modified: 2010-11-05 15:27 UTC (History)
4 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Ryan Abel (reporter) maemo.org 2010-05-26 06:58:14 UTC
SOFTWARE VERSION:
10.2010.19-1

EXACT STEPS LEADING TO PROBLEM: 

1. Open browser.
2. Load any thread on http://talk.maemo.org/ (say,
http://talk.maemo.org/showthread.php?t=53551)
3. Double-tap posts column to zoom into it.

EXPECTED OUTCOME:
Zoom into posts column on double-tap.

ACTUAL OUTCOME:
No zoom in, occasionally zooms OUT to minimum.

REPRODUCIBILITY:
6/7

OTHER COMMENTS:
Sometimes you can get it to zoom into bulleted lists or quotes in posts, but
it'll never zoom to normal text in the posts column.


User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US)
AppleWebKit/531.9+(KHTML, like Gecko, Safari/528.16) OmniWeb/v622.10.0
Comment 1 tuukka.tolvanen nokia 2010-05-26 10:55:11 UTC
By the looks of it you get zoomed to fit the post body (<div
class="postdetails"> or thereabouts?) when you double tap a plain post content
paragraph -- it's the sort of thing that makes sense for e.g. images but
doesn't end up being the best choice here...

(As a random data point, a fennec trunk build from late April wins in this
case, but on the other hand it zooms to image width rather than entire image on
e.g. a flickr photostream page, which is less convenient)
Comment 2 Dawid Lorenz 2010-06-01 13:07:45 UTC
This issue should be renamed to something like:
"Double-tap to zoom text does not work properly (PR1.2 regression)"
So perhaps it will get more attention.

I've noticed this problem after upgrading to PR1.2. I visit some websites on
daily basis via my RSS feed and zooming for those sites was never a problem
with PR1.1(.1), while now I need to either swipe circles on screen or use
volume buttons, as double-tap to zoom does not always work, or - as Ryan stated
- sometimes zooms page OUT.

In my eyes, this is definitely a nasty regression introduced in PR1.2. :(
Comment 3 Ryan Abel (reporter) maemo.org 2010-06-01 15:30:45 UTC
(In reply to comment #2)
> This issue should be renamed to something like:
> "Double-tap to zoom text does not work properly (PR1.2 regression)"
> So perhaps it will get more attention.
> 

No, because then it's generic and generally useless to the developers. :) This
bug is about zooming to the posts column on Talk. Zooming to <insert element
here> on <insert site here> may not work for completely different reasons, so
lumping all of those behaviors into a single bug is counterproductive.

Besides, I've found double-tap zooming to be, in general, much easier to use
than in previous releases (partially because text rendering isn't fubared
anymore, of course).

> I've noticed this problem after upgrading to PR1.2. I visit some websites on
> daily basis via my RSS feed and zooming for those sites was never a problem
> with PR1.1(.1), while now I need to either swipe circles on screen or use
> volume buttons, as double-tap to zoom does not always work, or - as Ryan stated
> - sometimes zooms page OUT.
> 

So file a new bug for each element on each site you're having problem with. If
they're related, they can be duped afterwards.
Comment 4 tuukka.tolvanen nokia 2010-06-01 21:12:47 UTC
> By the looks of it you get zoomed to fit the post body (<div
> class="postdetails"> or thereabouts?) when you double tap a plain post content
> paragraph -- it's the sort of thing that makes sense for e.g. images but

to clarify, if there were paragraph elements, things would work out better;
here you have <br><br>s and a narrow layout, which together make hitting this
issue often fairly likely.
Comment 5 Ryan Abel (reporter) maemo.org 2010-06-02 04:30:47 UTC
(In reply to comment #4)
> > By the looks of it you get zoomed to fit the post body (<div
> > class="postdetails"> or thereabouts?) when you double tap a plain post content
> > paragraph -- it's the sort of thing that makes sense for e.g. images but
> 
> to clarify, if there were paragraph elements, things would work out better;
> here you have <br><br>s and a narrow layout, which together make hitting this
> issue often fairly likely.
> 

Ah, interesting, because I'm having the same problem here on Bugzilla. This
means we can fix the HTML-compliance of the forum software in the mean time,
anyway. Cool.
Comment 6 Ryan Abel (reporter) maemo.org 2010-06-02 04:38:21 UTC
Just a heads up, I've filed bug #10488.
Comment 7 Dawid Lorenz 2010-06-02 13:52:00 UTC
(In reply to comment #3)
> So file a new bug for each element on each site you're having problem with. If
> they're related, they can be duped afterwards.
> 

Filed #10495
Comment 8 Pekka Vanhoja 2010-06-17 12:25:41 UTC
Hmm, interesting, for some reason the code seems to interpret it is zooming on
an image when double-tapping on the post content in talk.maemo.org. So just be
sure, this has not happened in talk.maemo.org posts before PR1.2, right?
Comment 9 Pekka Vanhoja 2010-06-17 13:40:24 UTC
(In reply to comment #8)
> So just be
> sure, this has not happened in talk.maemo.org posts before PR1.2, right?

Reply to myself. :) Yep, it's a regression. Tested with PR1.1.1 and there it
did not happen.
Comment 10 Pekka Vanhoja 2010-06-17 15:09:07 UTC
(In reply to comment #8)
> Hmm, interesting, for some reason the code seems to interpret it is zooming on
> an image when double-tapping on the post content in talk.maemo.org.

Ah, that bit of code has been there since the dawn of days. Continuing
investigation.
Comment 11 tuukka.tolvanen nokia 2010-06-17 22:28:49 UTC
> Reply to myself. :) Yep, it's a regression. Tested with PR1.1.1 and there it
> did not happen.

yeah ...I tracked down the regressing change, but it wasn't immediately obvious
to be why it has this effect
Comment 12 Dawid Lorenz 2010-06-18 00:38:09 UTC
(In reply to comment #11)
> > Reply to myself. :) Yep, it's a regression. Tested with PR1.1.1 and there it
> > did not happen.
> 
> yeah ...I tracked down the regressing change, but it wasn't immediately obvious
> to be why it has this effect

Does that change also explains issue explained in
https://bugs.maemo.org/show_bug.cgi?id=10495 ?
Comment 13 Pekka Vanhoja 2010-06-21 11:53:38 UTC
(In reply to comment #12)
> Does that change also explains issue explained in
> https://bugs.maemo.org/show_bug.cgi?id=10495 ?

There's a patch ready for this bug and it fixed the bug 10495 too.
Comment 14 Andre Klapper maemo.org 2010-06-29 13:20:31 UTC
This has been fixed in packages
tablet-browser-view 2.2.6-1.15+0m5
microb-eal 2.9.5-1.22+0m5
browser-eal 0.5.5-6.5+0m5
which is part of the internal build version
2010.26-1
(Note: 2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 15 Andre Klapper maemo.org 2010-10-25 17:13:54 UTC
The problem reported here should be fixed in the update that was released today
for public: The Maemo5 update version 20.2010.36-2 (also called "PR1.3"
sometimes). Please leave a comment if the problem is not fixed for you in this
update version.
Comment 16 Dawid Lorenz 2010-11-05 15:27:29 UTC
I can confirm this issue as resolved in PR1.3