Feodor2
Mouse wheel scroll broken on some text fields
я где то упоминал что над текстовыми полями скролл с колесика поломалсо но щас в упор не могу найт где
ну вот я проверил на чистом портабле браузере и до скролл действительно поломалсо
можно проверить на спойлере hashes который разворачивает такой нескролябельный текст https://github.com/win32ss/supermium/releases
mypal-74.1.4.en-US.win32 не скролит
mypal-68.14.2.en-US.win32 не скролит
mypal-68.13.8.en-US.win32 не скролит (проверено 2 раза)
mypal-68.13.7.en-US.win32 скролит
mypal-68.13.5.en-US.win32 скролит
mypal-68.13.4.en-US.win32 скролит
mypal-68.13.1.en-US.win32 скролит
можно проверить на спойлере hashes который разворачивает такой нескролябельный текст
Для справки - это не текстовое поле, а элемент <pre>. И прокрутки над ним нет потому, что у него есть его собственные полосы прокрутки (две, просто вертикальная невидима, так как имеющееся содержимое в элемент поместились). Вот этим полосам события от мыши, скорее всего, и достаются - даже той, которая не видна.
А наличие полос обеспечивается строкой "overflow: auto;" в его стилях.
Когда я эту строку Инспектором отключил, прокрутка страницы тут же заработала.
Подозреваю, что <pre> к делу не относится, и то же самое будет и с любым другим элементом, имеющим невидимую полосу вертикальной прокрутки.
почему в хроме 100500 это работает? ... перепроверил в 138-м supermium-е все молча крутитсо
ты не смотрел это на обоих старом и новом браузерах? или можот просто они новому фф такую html-ку подсовывают?
опять же есть быдлостраницы без стандартной полосы прокрутки и над ними колесо работает
ну и в предыдущих версиях все это работало тоже хотя небось элемент не сильно новый
почему в хроме 100500 это работает?
А разве я говорю, что не должно? Я просто показал, что именно даёт такой эффект.
или можот просто новому фф такую html-ку уже подсовывают?
Скорее, это или ошибка внесена при перетаскивании какого-то кода FF в Mypal, или оно от новых FF унаследовано. Но это нужно нынешние FF смотреть, а мне негде.
опять же есть быдлостраницы без стандартной полосы прокрутки и над ними колесо рабоатет
Прокрутка страницы к делу не относится. Проблема проявляется, когда мышка стоит над элементом, имеющим свою собственную прокрутку. (Полос прокрутки две - вертикальная и горизонтальная, их видимость управляется независимо, и можно было бы ещё поэкспериментировать, чтобы уточнить, при каких именно состояниях проблема проявляется, но не знаю, надо ли.)
хотя небось элемент не сильно новый
Настолько "не сильно", что существовал даже в самой первой версии HTML. Только, как я уже написал, скорее всего, что дело не в конкретном элементе, а проблема будет над любым, имеющим свою собственную полосу верткальной прокрутки (пусть даже и невидимую).
но не знаю, надо ли.)
ну подождем реакцию feodor2-а
а так до надо бы глянуть в оригинальном фф но умя такого тожо неп а все виртуалки пришлось снести...
Только, как я уже написал, скорее всего, что дело не в конкретном элементе, а проблема будет над любым, имеющим свою собственную полосу верткальной прокрутки (пусть даже и невидимую).
Проверил с <div> - всё то же самое. Только более детальные эксперименты показали, что вертикальная прокрутка страницы отваливается, если:
- у элемента есть полоса горизонтальной прокрутки И
- есть, что по горизонтали прокручивать.
Если полоса горизонтальной прокрутки видима но недоступна (т.к. строки короткие), то прокрутка страницы работает.
Вот образец выложил: http://mypal68.mywebcommunity.org/noscroll.htm
ну по крайней мере в обычных окнах с горизонтальной прокруткой и где есть чего скролить скролл работает как надо
а вот где найти еще поля с горизонтальной прокруткой ирл яхз
Естественно. Прокрутка же отрубается не глобально, а только когда мышка находится над "нехорошим" элементом. Скорее всего, события колеса "съедаются" этим элементом и не передаются нижележащим. (А страница в целом (элемент <body>) - это самый нижний элемент, практически фон, поверх которого лежит всё остальное.)
А если на странице вообще ни одного подобного элемента нет, то и ситуация такая в принципе не возникает.
вот кстате раз речь за поле ввода с этими скролящимися списками внутри скролящихся списков есть другой феил
сам списочек захватывает фокус если повисеть пол секунды над ним в итоге ты можешь скролить страницу без остановки но вот стоит тебе немножко зазеватсо и фокус подхыватывает такое поле и скролл уже начинаетсо в нем
можот имеет какоето отношение и к этому мож самозахватываетсо фокус но некуда сткролить?
...хотя тут у нас скролл стопоритсо моментально стоит тебе доскролить до такого поля и собственно это и основная проблема тк это поле непреодолимая преграда при листании страницы
Ой не знаю. На страницах developer.mozilla.org и ещё много где я такие чудеса встречал с этой непредсказуемой прокруткой, которые никакой логикой объяснить невозможно. Типа: мышка стоит над элементом с вертикальной прокруткой, но прокрутка колесом в этом элементе не работает. Или ещё круче - работает, но крутит не этот элемент, а какой-то совершенно посторонний.
...хотя тут у нас скролл стопоритсо моментально стоит тебе доскролить до такого поля
Не "доскролить до", а именно расположить курсор мыши над этим элементом. Вон, на моей тестовой странице блоки рамочкой обведены. Когда мышка справа от блока, прокрутка не отрубается.
Не "доскролить до", а именно расположить курсор мыши над этим элементом.
ну я про то что для скролящихся полей для захвата нужно повисеть над полем а потом оно захыватваетсо через время (и можно проскролить это место вполне) (хотя можот это время регулируетсо самой жабой?) а тут просто курсор оказалсо над и все моментально стали
Это ты сейчас пишешь о проявлениях парочки других проблем, присутствующих в любом браузере, и, судя по всему, неустранимых. Во всяком случае, не настраиваемых.
-
Когда мышка движется, она о своих перемещениях информирует операционную систему, посылая ей пакеты, содержащие информацию о величине перемещения. В предельном случае такое извещение она должна посылать при каждом перемещении на 1 пиксел по любой из координат. Но разрешение у мышек довольно высокое, а перемещать их можно весьма быстро, и чтобы не перенапрягать операционку, очередной пакет уходит не при перемещении на 1 пиксел, а пореже. Хорошо так "пореже".
-
О перемещениях мыши браузер узнаёт от операционной системы и извещает о них элементы странички. Но делает он это ещё реже, чем ему операционка о них говорит. (Та, которая, в свою очередь, получает их от мыши "с пропусками".) И в результате элемент получает извещение, что мышка на него наехала, не тогда, когда мышка только-только пересекла его границу, а с изрядным опозданием, когда мышка уже в него изрядно углубилась. Я об это дело больно обжёгся в одном из своих веб-проектов - при быстром перемещении мыши сообщение о пересечении границы приходило элементу, когда курсор уже влетал в него пикселов на 100-150, если верить координатам мыши, находящимся в этом сообщении. Но реально мышка была ещё дальше, чем эти координаты говорили. А если элемент быль не столь велик, то мышка пролетала над ним, а браузер элементу извещение вообще не присылал.
Но это касается тех извещение, которые браузер элементам шлёт (редко). Сам-то он извещение от ОС получает чаще, и поэтому обнаруживает попадание мыши на элемент с прокруткой оперативнее. Полосы прокрутки обслуживает не JS-код страницы, а сам браузер. А слать элементу извещение в нашем случае не требуется - элемент об этом не просил (обработчик события для него никто не назначал.)
АГА это мыша щитаетсо статичной видимо и от нее сообщения не идут когда скролишь колесом если ЖЕ елозить мышом над внутреним скролящимся полем и скролить одновременно то уже проскролить это место так же не получаетсо возможно у обоих проблем одни и те же уши
и, судя по всему, неустранимых. Во всяком случае, не настраиваемых.
нет это проблема кривых софтов которые захватывают фокус ввода по наведению когда должны это делать по клику по этому полю
так же куча быдло софтов которые захватывают корсор по единичному клику вместо двойного в итоге невозможно на эти софты просто перевести фокус не потеряв курсор в них... (эт можно встретить в каждом 2-м эмуляторе (если не в каждом 1-м (в моем таких проблем нет фикс 2 строчки кода)))
да и впринципе на браузер ты тоже не можешь перевести фокус не кликнув что либо попутно и если в фф еще можно включить нормальные менюшки и панели с титлбаром то в хромом это все сплошные кнопки 99% площади окна
это мыша щитаетсо статичной видимо и от нее сообщения не идут когда скролишь колесом
Идут-идут. Каждый щелчок мыши или колеса передаётся - они же чудовищно редкие по сравнению с 1200 пакетов на дюйм перемещения, особенно когда мышка за секунду пролетает дюймов десять. Причём в каждом пакете вместе с состоянием кнопок передаётся и величина перемещения. Да, если мышка не двигалась, то там будут нули, но не передавать их нельзя - просто потому, что формат пакета фиксированный.
нет это проблема кривых софтов которые захватывают фокус ввода по наведению
Это ещё в доинтернетные времена началось - в Юниксе (X-Window). И даже для Windows примочки были, которые подобное поведение реализовывали. А потом и сама Microsoft туда же потянулась - с их самораскрывающимися подменюшками (а иногда и самозакрывающимися). "Повбывав бы гадив!"
Идут-идут. Каждый щелчок мыши или колеса передаётся
не я про то что скролл колесиком не щитаетсо перемещением мыши и захват фокуса не срабатывает но стоит мышу при скролле двинуть так захват сразу и глобальный скролл страницы стопорицо на скролле поля со скроллом
по сравнению с 1200 пакетов на дюйм перемещения
да никто и не передает столько в венде передаеют если сдвинулось на видимый пиксель вроде (но это не точно)
да и там частота опроса вообще кстате около 100Гц +-50 даже есть всякие патчинги драйверов юсб чтоб его поднять а когда ты частоту так задираешь скорость курсора пропорционально ВНЕЗАПНО падает и тебе уже не хватает дефолтного множителя
так что про 1200 пакетов это ты совсем уже мимо
вот можошь подрыгать свою мышу mouserate.zip
ну и там есть всякие игровые мышки со 1600Гц-ами или около того
