In my opinion this is not a but. It's a feature.
For me it is more important to zoom a website in and out. I use this more often
than volume changes. But you're right.
I would prefer a option in the Settings for all people that would prefer a
volume change with the hardware Buttons.

In my opinion most people would prefer the zooming!

There are several other ways to zoom (the circle gesture, double-tapping, ...)
but none to turn down the volume of a media-rich web page quickly.

look, some people want absolute control over zooming, that's only possible w/
some slider interface, today the only way to do that is with the hardware keys.

it's probably possible to arrange things such that if you held one of shift,
fn, or ctrl while using the hardware keys,p you'd get the other behavior....

it sounds like you have a specific requirement to instantly mute/pause flash,
that's an absolutely reasonable requirement/request but it should be covered in
its own bug. I'll talk w/ our flash team after this movie.

Comment 4 Andre Klapper 2009-12-09 19:57:45 UTC

This is currently discussed for a future Maemo release. Setting Target
Milestone.

Why can't these things be commented openly?

It appears that the current proposal (and it's just that until it's
implemented) is that this be a user facing preference.

Still valid in 1.2009.51-1

Might be an option to provide an alternate way to change volume or zoom -
shift-vol+/-.

Comment 9 Nagineni Sudarsana Babu 2010-01-07 12:39:41 UTC

i'm looking into this

Comment 10 Faheem Pervez 2010-01-10 10:04:21 UTC

(In reply to comment #3)
> look, some people want absolute control over zooming, that's only possible w/
> some slider interface, today the only way to do that is with the hardware keys.
>
Some people just want an option.

Me? I just resort to using xprop to unset _HILDON_ZOOM_KEY_ATOM on the
browser's window.

(In reply to comment #2)
> There are several other ways to zoom (the circle gesture, double-tapping, ...)
> but none to turn down the volume of a media-rich web page quickly.
> 

I also agree. There are several other ways to zoom. When, for instance, I am
seeing a YouTube video I have to press the power button (quick way of "unfocus"
the browser) before using the volume keys.

re comment 8, andrey: that's indeed covered by paragraph 2 of comment 3.

in the future, please do read bugs before commenting.

re comment 11, claudio: we don't need agreement, no one challenged the
statement. Bugzilla is not a forum.

The lifecycle of a bug:
1. a reporter tries as hard as possible to file a bug about a problem with as
much precision as possible and the smallest scope possible to make it as easy
as possible for others to reproduce and engineers to fix.
2. when the reporter fails, someone either helps to clarify or asks the
reporter questions until the ideal state is reached.
3. the bug is assigned to an engineer and work begins.
4. if the engineer needs further input, the engineer asks for it.
5. the engineer develops a fix.
6. if the engineer's review partners and testers use the bug tracker in
question, a patch is attached, and it is reviewed and tested until the
reviewers and testers are happy.
7. the engineer commits a fix (and marks the bug as fixed)
8. the fix becomes available
9. the bug filer or someone else updates to a version of the product and has an
opportunity to comment.
10. If the bug is fixed they indicate "I verify that this bug is fixed" (and if
they're allowed to, they change the status to verified). We all go home.
11. If they find that the problem is not fixed, they provide the version they
were testing, the steps they used to reproduce (even if they're exactly the
same as the original comments), and the results they got.
12. The engineer either reopens, possibly apologizing, or explains "no, that's
a new bug, please file it"

That's the lifecycle of a bug. Bugs do not want to wonder off, they want to be
short, they do not want people to have to explain the lifecycle of a bug in
each and every bug, and they do not want unnecessary comments (such as yours or
mine).

re comment 5, aniello: I believe I noted to you privately, but..., my analysis
was public, the decisions made by people at Nokia are fairly random and do not
necessarily have any affect on what actually ends up reaching the customer
product. When someone from "Nokia" makes a statement, people usually treat it
as a contract and/or abuse the person for making it. If the statement from
Nokia doesn't reflect what happens in the future, people complain. As such,
some of us try not to make promises we can't keep. This bug was actually a good
example, as the original change was to just mandate a behavior that was
different from the behavior that was seen by customers in FCS. However, that
"change" will never reach you guys. The current work is the proposal listed in
comment 6, and there's a note from the assignee in comment 9 indicating that he
might look into something else (hopefully comment 3 paragraph 2).

Roughly: this is a long winded way of saying "please do not comment needlessly
in bugzilla, if you feel that you have something to say, perhaps you should use
brainstorm".

Comment 13 Andre Klapper 2010-02-17 21:02:30 UTC

This will be fixed in PR1.2:

"In the browser, the user to change the function of De/increase key according
his/her very personal needs. Go the View menu of a browser window, tap on
'Options', then 'Settings' and then via the 'Use the increase and decrease key
for' button select the wanted function, zooming or volume"

A future public update will include the fix. (This is not always already the
next public update.)

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 14 Andre Klapper 2010-03-15 20:51:17 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).

Thank you _very much_ for making this optional. IMHO a good decision.