Der Chrome zeigt während des Tests
Chrome is being controlled by automated test software
an? Das kann Dir die Click-Events verschieben (um etwa 100px nach oben) 🙄 Fix:
|
1 2 3 |
ChromeOptions options = new ChromeOptions(); options.addArguments("disable-infobars"); driver = new ChromeDriver(options); |
UPDATE: Ein paar Tage später sind die Koordinaten wieder verschoben; lag also nicht (nur?) daran!
kalauer mitwoch! pic.twitter.com/faqYQHoA7W
— Alex (@alexmilde) June 6, 2018
Setup: Ein Hifiberry Amp2 auf einem Raspberry 3 B+.
Frage: Welches OS nutzt man jetzt? Laut Internet stehen Volumio, RuneAudio und moOde. Alle drei basieren auf demselben Ursprungsprojekt, also ene mene muh:
None of the existing Rune images will work on the new Pi 3B+.
sudo wget -q http://moodeaudio.org/downloads/mos/mosbuild.sh -O /home/pi/mosbuild.shsudo chmod +x /home/pi/mosbuild.shsudo ./mosbuild.shAngesichts des UI habe ich dann auch keine Lust, mich weiter damit zu befassen.
If the software you’re using doesn’t provide the Amp2 as an output option, you should use the HiFiBerry DAC+ driver as the Amp2 is basically a DAC+ with an integrated power stage.
Aber zurück zur Lautstärkenregelung: Laut Entwickler vom Hifiberry ist das ein Problem von Volumio, zumal alsamixer funktioniert. Und tatsächlich: Das Problem ist (indirekt) das UI. Man muss unter “Playback Options” → “Volume Options” → “Mixer Control Name” von “Analog” auf “Digital” wechseln und speichern. Das Pop Up a la “Alles gespeichert und neu gestartet” muss man ignorieren und den Pi neustarten.
Dann geht’s.
Angenommen, ich bin auf www.google.com. Doppelklicke ich auf “google”, dann erwarte ich, dass “google” ausgewählt wird. Der Firefox (unter Ubuntu) wählt aber – und das schon beim ersten Klick – alles aus. Absolut nervig, und auch anders als überall sonst. Ich kann es nicht leiden, wenn Software schlauer sein möchte als der Benutzer 😠 Leider funktioniert Pale Moon immer schlechter, Renderfehler etc., aber das ist ein anderes Thema.
Also:
|
1 |
browser.urlbar.doubleClickSelectsAll = false |
stellt das korrekte Verhalten wieder her. Und wenn man schon mal da ist, kann man direkt
|
1 |
browser.urlbar.clickAtEndSelects = true |
setzen. Von.
Eine bessere Übersetzung Umschreibung für text-overflow ist mir nicht eingefallen 🙃
In jQuery ginge das so:
|
1 2 3 4 5 6 7 8 |
$.expr[':'].truncated = function (e) { // ggf. Style checken, bspw. // $(e).css('text-overflow') === 'ellipsis' return e.offsetWidth < e.scrollWidth; }; // dann: let items = $('.your-selector:truncated'); |
Cross-post; basiert auf den Antworten hier. Bonus: In Selenium geht das so:
|
1 2 3 4 5 6 7 8 9 10 |
WebElement element = ...; // element is truncated? double offsetWidth = Double.parseDouble(element.getAttribute("offsetWidth")); double scrollWidth = Double.parseDouble(element.getAttribute("scrollWidth")); assertThat(offsetWidth < scrollWidth).isTrue(); // truncation style is ellipsis? String overflowStyle = element.getCssValue("text-overflow"); assertThat(overflowStyle).isEqualTo("ellipsis"); |
bäm.
Wer mit Selenium Touchgesten simulieren will (hier: Pull-to-Refresh 🙂), der benötigt zuerst mal einen Browser, der Touch unterstützt:
|
1 2 3 4 5 6 7 8 9 10 |
Map<String, Object> someDeviceMetrics = ...; // see link Map<String, Object> emulation = new HashMap<>(); emulation.put("deviceMetrics", someDeviceMetrics); emulation.put("userAgent", "<some user agent>"); ChromeOptions options = new ChromeOptions(); options.setExperimentalOption("mobileEmulation", emulation); WebDriver driver = new RemoteWebDriver(SELENIUM_URL, options); |
Der Rest ist dann einfach:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public class Browser implements HasTouchScreen, ... { // ... @Override public TouchScreen getTouch() {{ return driver instanceof HasTouchScreen ? ((HasTouchScreen) driver).getTouch() : new RemoteTouchScreen(new RemoteExecuteMethod((RemoteWebDriver) driver)); } } // ... // offsetX/offsetY = the distance to be panned new TouchActions(getBrowser()) .flick(target, offsetX, offsetY, 200) .perform(); |
(wenn man davon absieht, dass der vierte Parameter laut Sourcecode 0, 1 oder 2 sein sollte, nicht 200 – getestet mit selenium-java 3.9.1)
Pull-to-refresh in (mobilen!) Webseiten nachzubauen, ist jetzt keine Raketenwissenschaft, aber doch so viel Aufwand, dass sich ggf. eine Library lohnt. Viele (? einige? apeatling, ember-gestures, …) bauen aber auf hammer auf, und das hat einen Bug (Beispiel, es gibt weitere Tickets) im Zusammenspiel von Panning (also dem “Pull” in “Pull-to-refresh”) und Scrolling. Zusammengefasst: Es geht nur eines von beiden. Mit ein wenig Drumherumgehacke bekommt man das etwas näher zusammengeführt, aber entweder kommt PanEnd dann gar nicht (was das “refresh” schwierig macht), oder bspw. die PanMove-Events kommen nicht zuverlässig (wodurch man den “pull” nicht 1:1 an den Finger des Nutzers hängen kann).
Ein npm-Modul, das nicht auf hammer aufbaut, wäre pulltorefreshjs (getestet mit 0.1.11 und 0.1.13):
|
1 2 3 4 5 6 |
PullToRefresh.init({ mainElement: '.myCssSelector', onRefresh: () => { console.log('hello moto') }, }); |
In Ember sieht das als Komponente so aus:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
import Component from '@ember/component'; import PullToRefresh from 'npm:pulltorefreshjs'; import {get, set} from '@ember/object'; import {getOwner} from '@ember/application'; import {inject as service} from '@ember/service'; export default Component.extend({ classNames: ['pull-to-refresh'], router: service(), currentRouteInstance: undefined, didInsertElement() { this._super(...arguments); const owner = getOwner(this); const currentPath = owner.lookup('controller:application').currentPath; set(this, 'currentRouteInstance', owner.lookup(`route:${currentPath}`)); // TODO use unique identifier for mainElement, store result of init() PullToRefresh.init({ mainElement: '.pull-to-refresh', onRefresh: () => { get(this, 'currentRouteInstance').refresh(); }, }); }, willDestroyElement() { this._super(...arguments); // TODO destroy current ptr only; id is returned by init() PullToRefresh.destroyAll(); }, }); |
Auf dem Handy sollte das so schon funktionieren. Auf dem Desktop hatte ich das Phänomen, dass Hochcrollen immer erst beim zweiten mal funktioniert hat (und auch dann nur, wenn zwischen Versuch 1 und 2 nicht zu viel Zeit lag). Weil: Die Lib immer beim Hochscrollen den Loader anzeigt, wenn man die Funktion shouldPullToRefresh nicht vom default !window.scrollY ummapt, bspw. auf
|
1 2 3 4 |
shouldPullToRefresh: () => { let scrollTop = this.$().parent()[0].scrollTop; return scrollTop === 0; }, |
Hochscrollen geht sonst nur, so lange der Loader angezeigt wird 🙃
Wer, wie ich, die verfilzte komplexe Javascript-Umgebung etwas… “unübersichtlich” findet, und sich fragt, wie zur Hölle man ein nicht-Ember-spezifisches npm-Modul in Ember importiert, dem kann geholfen werden:
Erst Browserify:
|
1 |
npm install ember-browserify --save-dev |
dann, voilà:
|
1 |
import PullToRefresh from 'npm:pulltorefreshjs'; |
Anwendungsfall: Eine Bedienungsanleitung in Form eines PDFs in einem neuen Fenster/Tab öffnen. Internet sagt (hier am Beispiel Ember):
|
1 |
window.open('anleitung.pdf'); |
Das funktioniert grundsätzlich auch in Fullscreen Web Apps, aber da solche Apps keine Browsernavigation anzeigen, kommt man ggf. „nie wieder“ aus der geöffneten Seite raus. Abhilfe schafft
|
1 2 3 4 |
var a = document.createElement('a'); a.setAttribute('href', 'anleitung.pdf'); a.setAttribute('target', '_blank'); a.click(); |
, was anleitung.pdf im „richtigen“ Browser anzeigt, statt innerhalb der App.