Open
Bug 1199861
Opened 9 years ago
Updated 2 years ago
Zooming with Ctrl+Scroll mouse wheel doesn't work if mouse is hovered over form controls
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox43 | --- | affected |
People
(Reporter: arni2033, Unassigned)
References
()
Details
STR: (Win7_64bit, Nightly 43.0a1 32bit ID 20150828030205, new profile)
1. Open New Tab page
2. Hover mouse over one of the following buttons: gear/pin tile/close tile/search submit.
3. Press Ctrl key (don't release it)
4. Scroll mouse up or down to change zoom
Result: Nothing happens.
Expectations: Zoom level should change, because that's default hotkey for changing zoom (sic!)
Summary: Zooming new tab page doesn't work if mouse is hovered over <input type="button"> or <input type="submit"> → Zooming new tab page with Ctrl+Mousewheel doesn't work if mouse is hovered over <input type="button"> or <input type="submit">
It happens (a) on any page (b) with any form controls. It's caused by this line:
http://mxr.mozilla.org/mozilla-central/source/dom/events/EventStateManager.cpp#2134
if (content &&
!content->IsNodeOfType(nsINode::eHTML_FORM_CONTROL) &&
!nsContentUtils::IsInChromeDocshell(content->OwnerDoc()))
{
Is this bug intentional? What is the reason to keep this bug? It occurs with <input>'s border, which
is usually 1-2px in width (i.e. accidentally). In my view that line should be deleted to fix this trap
Component: New Tab Page → Event Handling
Flags: needinfo?(masayuki)
Product: Firefox → Core
Summary: Zooming new tab page with Ctrl+Mousewheel doesn't work if mouse is hovered over <input type="button"> or <input type="submit"> → Zooming with Ctrl+Scroll mouse wheel doesn't work if mouse is hovered over form controls
Comment 2•9 years ago
|
||
I didn't know the reason but I found the original bug which excludes form controls and XUL contents. That is bug 65355. That tried to fix unintentional behavior of <select>. Even in these days, it sounds good to me that disabling zoom on <select> because momentum wheel events may cause unintentional zoom when user tries to select multiple items on a listbox.
In other words, if the form control isn't a <select multiple> element, it doesn't make sense to disable zoom even on form controls.
Flags: needinfo?(masayuki)
I don't know how you found bug 65355, but that's impressive.
Still my suggestion is to delete that line, given:
(1) 65355 asked for illogical thing: it's not possible to accidentally make Ctrl+Scroll instead of
Ctrl+Click in <select>. I mean, such person is hitting problems with zooming/scrolling everywhere.
(2) 65355 hasn't (ever?) achieved the goal of disabling Ctrl+Scroll, because (just like in the case
with <input>, Ctrl+Scroll is only disabled on border+padding of <select multiple> which is ~3px)
(3) 65355 is reopened, so it's safe to remove that line instead of fixing completely broken code:
if that bug will ever considered valid and/or useful, the correct patch will be landed in that bug
> URL data:text/html,<select multiple><option>1<option>2<option>3<option>4<option>5<option>6<option>7<option>8<option>9<option>10<option>11<option>12<option>13<option>14<option>15<option>16<option>17<option>18<option>19<option>20<option>21<option>22<option>23<option>24<option>25<option>26<option>27<option>28<option>29</select>
Assignee | ||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•