Bug 6342 - (int-150437) Use Volume hardware key for adjust the device volume instead of zooming a website
(int-150437)
: Use Volume hardware key for adjust the device volume instead of zooming a web...
Status: VERIFIED FIXED
Product: Browser
User interface
: 5.0/(3.2010.02-8)
: N900 Maemo
: Low minor with 10 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: Nagineni Sudarsana Babu
: browser-bugs
:
:
:
: 6347
  Show dependency tree
 
Reported: 2009-11-26 17:43 UTC by Uwe Kaminski
Modified: 2010-06-03 19:23 UTC (History)
11 users (show)

See Also:


Attachments


Note

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


Description Uwe Kaminski (reporter) 2009-11-26 17:43:24 UTC
SOFTWARE VERSION:
1.2009.42-11

STEPS TO REPRODUCE THE PROBLEM:
1. Start browser
2. Press the + or - hardware buttons.

EXPECTED OUTCOME:
Audio volume change.

ACTUAL OUTCOME:
Website zooming in or out.

REPRODUCIBILITY:
Always.

There should be a general solution. See also Bug 5387 AND Bug 6048
Comment 1 redex 2009-12-04 13:05:08 UTC
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!
Comment 2 Daniel Fischer 2009-12-07 09:20:49 UTC
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.
Comment 3 timeless 2009-12-07 17:46:58 UTC
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 maemo.org 2009-12-09 19:57:45 UTC
This is currently discussed for a future Maemo release. Setting Target
Milestone.
Comment 5 Aniello Del Sorbo 2009-12-09 20:01:17 UTC
Why can't these things be commented openly?
Comment 6 timeless 2009-12-10 02:13:11 UTC
It appears that the current proposal (and it's just that until it's
implemented) is that this be a user facing preference.
Comment 7 Uwe Kaminski (reporter) 2009-12-26 02:42:11 UTC
Still valid in 1.2009.51-1
Comment 8 Andrey Kudinov 2010-01-06 12:23:48 UTC
Might be an option to provide an alternate way to change volume or zoom -
shift-vol+/-.
Comment 9 Nagineni Sudarsana Babu nokia 2010-01-07 12:39:41 UTC
i'm looking into this
Comment 10 Faheem Pervez maemo.org 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.
Comment 11 Cláudio F. Gil 2010-01-13 15:44:25 UTC
(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.
Comment 12 timeless 2010-01-13 17:20:14 UTC
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 maemo.org 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 maemo.org 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).
Comment 15 Uwe Kaminski (reporter) 2010-06-03 19:23:02 UTC
Thank you _very much_ for making this optional. IMHO a good decision.