maemo.org Bugzilla – Bug 6342
Use Volume hardware key for adjust the device volume instead of zooming a website
Last modified: 2010-06-03 19:23:02 UTC
You need to log in before you can comment on or make changes to this bug.
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
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.
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+/-.
i'm looking into this
(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".
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/
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.