46
Sítě / Re:Detekce měřeného datového připojení
« kdy: 14. 03. 2021, 19:26:51 »
Aha, zajímavé
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
47
Windows a jiné systémy / Re:USB zařízení se někdy chová jako CD
« kdy: 14. 03. 2021, 19:22:56 »něcím podobným jsem se kdysi snažil opravit nějakou lexar flashku co nějak přestala fungovat nebo se jí zkrátila kapacita na půl... Myslím že na to funguje jen na flashky
Pokud jsem se sekl a hodil link na Tool, co s tím nemá nic společného, tak si vys**chněte oko, už je to déle, co jsem to měl v ruce.
48
Windows a jiné systémy / Re:Windows: stará IP adresa z předchozí sítě
« kdy: 14. 03. 2021, 19:19:35 »
No teď už to před sebou nemám ale právě mám pocit, že při tom posledním připojení do sítě (do té původní) právě jsem tam NAK viděl. ale obsah paketu si už nevybavím. Ale je možné že ho windows ignorovaly třeba?
49
/dev/null / Re:web: Kde zjistit místo volání xmlrequestu (dohledání argumentu POST)
« kdy: 14. 03. 2021, 12:05:08 »
50
Odkladiště / Re:o2.cz Hodnota dobití
« kdy: 13. 03. 2021, 20:48:24 »
Jako už před 5 lety tyhle podmínky dobíjení (min.částka a vynucená platnost) o2 patřily suveréne k tomu nejhoršímu na trhu. Divím se, že má ještě zákazníky tato "firma"
51
/dev/null / web: Kde zjistit místo volání xmlrequestu (dohledání argumentu POST)
« kdy: 13. 03. 2021, 20:46:16 »
Mám takový oříšek (v prohlížeči chromium to řeším nyní), na nějaké hypermoderní stránce s webpackerem, kde jsou nějaké chunk soubory a téměř nečitelný jendořádkový javascript i po expanzi, v Sources je Could not load content for webpack:///./node_modules/@sentry/utils/esm/instrument.js (HTTP error: status code 404, net::ERR_UNKNOWN_URL_SCHEME) se nemohu dopátrat vzniku argumentu XMLHTTPREQUESTU... (vypadá to jako base64, ale nejde rozkodovat)
Takže to vypadá, že statickou analýzou javascriptů nevyčtu ani Ň.
Jediné čeho se dá chytit v devtools:
-tab Network - daný request - subtab Initirator - ale někdy to vede na ty zmíněné soubory, co nekorespondují se skripty načtenými ze stránky
- jak využít breakpointy (pravý sloupec Sources) :XHR/fetch breakpoints nebo EventListener breakpoints:XHR --- zkoušel jsem to a zachytilo to jen jednou ,ale nedostal jsem se kničemu důležitému
-hledal jsem i výskyt "Ctrl Alt F" : název domény (alb.reddit.com) nebo název (i.gif) -Nic nenalezeno
Čili jak "vytracovat" zpětně, co předcházelo volání requestu o ten obrázek i.gif?z=***
Kdo by to chtěl konkrétně řešit:
stránka reddit.com (desktopové zobrazení) : URL requestů je alb.reddit.com/i.gif?z=divný_řetězec - odkud se bere původ této hodnoty
Takže to vypadá, že statickou analýzou javascriptů nevyčtu ani Ň.
Jediné čeho se dá chytit v devtools:
-tab Network - daný request - subtab Initirator - ale někdy to vede na ty zmíněné soubory, co nekorespondují se skripty načtenými ze stránky
- jak využít breakpointy (pravý sloupec Sources) :XHR/fetch breakpoints nebo EventListener breakpoints:XHR --- zkoušel jsem to a zachytilo to jen jednou ,ale nedostal jsem se kničemu důležitému
-hledal jsem i výskyt "Ctrl Alt F" : název domény (alb.reddit.com) nebo název (i.gif) -Nic nenalezeno
Čili jak "vytracovat" zpětně, co předcházelo volání requestu o ten obrázek i.gif?z=***
Kdo by to chtěl konkrétně řešit:
stránka reddit.com (desktopové zobrazení) : URL requestů je alb.reddit.com/i.gif?z=divný_řetězec - odkud se bere původ této hodnoty
52
Windows a jiné systémy / Re:Android: blokace wildcard domén
« kdy: 12. 03. 2021, 17:07:28 »
Věděli byste odpovědi na tyto palčivé otázky? Více méně by to mělo být generické bez ohledu na použitý SW ale jen jde o architekturu DNS,API, funkčnosti u androidu, ta zdánlivá nefunkčnost DNS na portu 5300 bez root režimu. A nebo je potřeba nastavit nějaký další krok?
A ta nemožnost použít port 53 v root režimu není zásadní, akorát jsem to chtěl použít pro ověření , zda to funguje jak má.
A ta nemožnost použít port 53 v root režimu není zásadní, akorát jsem to chtěl použít pro ověření , zda to funguje jak má.
53
Windows a jiné systémy / Re:Windows: stará IP adresa z předchozí sítě
« kdy: 12. 03. 2021, 17:03:07 »
Asi po bugách windows nemá cenu pátrat...
S tou kolizí to může být pravda na půl: technicky by kolize neměla se stát, jelikož dle MAC toho počítače DHCP přiřadí určenou IP. A ta mac počítače je stejná i pro 5GHz síť i 2.4GHz (mají různé SSID a BSSID("MAC") lišící se o osmičku)
Takže jedinou podezřelou věc bych viděl, že nejdřív se windows mohl připojit na 2.4GHz, pak na tu síť z jiného zařízení a potom na 5GHz, a dostal stejnou IP i když to byla jiná wifi
PS: Je normální, že hotspot na smartphonu používá "randomizaci brány" : při každém zapnutí /vypnutí je IP adresa smartphonu(brány) jiná. ( IP: A.B.C.D : A,B:fixní z private scope, C,D, lišící se při zapnutí, D pool pro klienty (/24))
S tou kolizí to může být pravda na půl: technicky by kolize neměla se stát, jelikož dle MAC toho počítače DHCP přiřadí určenou IP. A ta mac počítače je stejná i pro 5GHz síť i 2.4GHz (mají různé SSID a BSSID("MAC") lišící se o osmičku)
Takže jedinou podezřelou věc bych viděl, že nejdřív se windows mohl připojit na 2.4GHz, pak na tu síť z jiného zařízení a potom na 5GHz, a dostal stejnou IP i když to byla jiná wifi
PS: Je normální, že hotspot na smartphonu používá "randomizaci brány" : při každém zapnutí /vypnutí je IP adresa smartphonu(brány) jiná. ( IP: A.B.C.D : A,B:fixní z private scope, C,D, lišící se při zapnutí, D pool pro klienty (/24))
54
Sítě / Re:Blokace reklamy na úrovni domácí sítě
« kdy: 12. 03. 2021, 16:54:58 »Spatne ci vubec, pokud vim.Na YT je to udělané agresivně., že blokace nějakých domény nepomůže (což ale neimplikuje, že by se neměly dotčené doméně blokovat). Dřív fungoval (možná ještě teď trik s"redirectem" ||doubleclick.net/instream/ad_status.js$script,redirect=doubleclick.net/instream/ad_status.js,important ) možná hypoteticky by šlo na úrovni sítě vyřešit spec. záznamem pro doubleclick.net a lokálním přesměrováním (musí to být nějaká odpověď - pro zájemce github/gorhil/ublock/wiki/staticfilters/scriptlets/resources/doubleclick). Ale dávno se už používá jiný recept:
Reklama pred, behem a po videu by mozna sla, ale Google rychle jakekoliv blokatory obejde zmenou odkud a jak se to posila. Vlozena reklama primo do videi asi nepujde nikdy.
Kód: [Vybrat]
youtube.com,youtube-nocookie.com##+js(json-prune, [].playerResponse.adPlacements [].playerResponse.playerAds playerResponse.adPlacements playerResponse.playerAds adPlacements playerAds)
youtube.com,youtube-nocookie.com##+js(set, ytInitialPlayerResponse.adPlacements, undefined)
youtube.com,youtube-nocookie.com##+js(set, playerResponse.adPlacements, undefined) musí to tedy běžet v prohlížeči s ublockem.. To je spolehlivéOno je to nějak plíživé, nepoužívá ublockové způsoby (ale jen obyč domény) tak to není, že by se mu reklama přehrávala imrvere,ale jednou za čas když to nečeká vůbec
...A nebo se vykašlat na stránky http youtube.com a používat klienta, youtube-dl nebo vlc , ale to asi je moc radikální
A nebo když nemůže ublock do prohlížeče, tak musí youtube přes proxy.
55
Windows a jiné systémy / Windows: stará IP adresa z předchozí sítě
« kdy: 12. 03. 2021, 00:53:39 »
Hele stala se mi na windows 7 divná věc. Připojuje se přes wifi. Domácí síť je 10.0.5.0/24., dokonce na 2 ssid.
Nyní (druhé připojení)jsem byl připojen na jiné wifi síti s rozsahem 10.0.24.0/24
Ale po připojení zpátky na původní síť mi
"nešel INTERNET" *** --- prostě systému zůstala IP adresa z druhé sítě . I když jsem se připojol na obě ssid opakovaně
čím to? Nějaký bug třeba se lease time?
Všiml jsem si že DHCP někdy kromě Discover,Offer,Request,Ack také dělá NAK.
*jelikož měl ip z rozsahu, která nepatří do sítě
Nyní (druhé připojení)jsem byl připojen na jiné wifi síti s rozsahem 10.0.24.0/24
Ale po připojení zpátky na původní síť mi
"nešel INTERNET" *** --- prostě systému zůstala IP adresa z druhé sítě . I když jsem se připojol na obě ssid opakovaněčím to? Nějaký bug třeba se lease time?
Všiml jsem si že DHCP někdy kromě Discover,Offer,Request,Ack také dělá NAK.
*jelikož měl ip z rozsahu, která nepatří do sítě
56
Sítě / Detekce měřeného datového připojení
« kdy: 10. 03. 2021, 00:38:23 »
na androidu je možné vybrat u wifi sítí zda jsou Měřené / Neměřené / nebo autodetekce. (Výstižnější než otrocky Metered je počítané)
A na základě čeho ta autodetekce funguje? Je tam nějaká hlubší myšlenka a algoritmus?
Já měl za to, že celular = automaticky počítané (i když teď je móda neomezených dat, ale pozor toto je jen pohled v ČR, android je celosvětový)
a wifi= automaticky počítané
A na základě čeho ta autodetekce funguje? Je tam nějaká hlubší myšlenka a algoritmus?
Já měl za to, že celular = automaticky počítané (i když teď je móda neomezených dat, ale pozor toto je jen pohled v ČR, android je celosvětový)
a wifi= automaticky počítané
57
Windows a jiné systémy / USB zařízení se někdy chová jako CD
« kdy: 09. 03. 2021, 23:55:36 »
Zdravím, mám wifi kartu do USB. Má tu debilní vlastnost, že po prvním připojení se hlásí jako CDROM . Když se vysune, objeví se konečně to pravé zařízení.
Jak je ale možné,
- že na jednom stroji (kde jsou už drivery ) po zasunutí do USB portu se pokaždé jeví jako CDROM zařízení je nutné ho pokaždé ejectovat?
- že na druhém stroji (kde jsou už taky drivery ) po zasunutí do USB portu rovnou hlásí jako wifi karta.
Jde o stroje Windows 7, 8.
Jak je to možné? Co to ovlivňuje, že se to chová jinak? Nějaká magie v "driverech / USB LowerFilters"? Sice nevím co to je, ale občas se to technických článeků zmiňuje (spolu s UpperFilters). Souvisí s tím také nějak WinUSB/LibUSB?
Na linuxu se to řeší pokud vím přes usbmodeswitch a udev pravidla. (BTW existuje pro linux.distribuci nějaký GUI
přívětivý manager těchto takto obskurně navrhnutých zařízení, který udržuje jejich seznam a co se s nimi má udělat (nějaká akce typu Eject, ale myslím, že kreativní designéři cetek, pseudomodemů, jsou schopni vymyslet něco proprietárního.)?
Jak je ale možné,
- že na jednom stroji (kde jsou už drivery ) po zasunutí do USB portu se pokaždé jeví jako CDROM zařízení je nutné ho pokaždé ejectovat?
- že na druhém stroji (kde jsou už taky drivery ) po zasunutí do USB portu rovnou hlásí jako wifi karta.
Jde o stroje Windows 7, 8.
Jak je to možné? Co to ovlivňuje, že se to chová jinak? Nějaká magie v "driverech / USB LowerFilters"? Sice nevím co to je, ale občas se to technických článeků zmiňuje (spolu s UpperFilters). Souvisí s tím také nějak WinUSB/LibUSB?
Na linuxu se to řeší pokud vím přes usbmodeswitch a udev pravidla. (BTW existuje pro linux.distribuci nějaký GUI
přívětivý manager těchto takto obskurně navrhnutých zařízení, který udržuje jejich seznam a co se s nimi má udělat (nějaká akce typu Eject, ale myslím, že kreativní designéři cetek, pseudomodemů, jsou schopni vymyslet něco proprietárního.)?
58
Windows a jiné systémy / android "personal DNS filter" - zkušenosti - port 53 a root
« kdy: 09. 03. 2021, 14:02:10 »
Vyzkoušel jsem https://www.zenz-solutions.de/personaldnsfilter-wp/. Provozuji v režimu BEZ VPN na LineageOS.
Mám k tomu několik postřehů a dotazů
1. WILDCARD domény
- hledaná vlastnost wildcard blokování mi funguje i bez nutnosti psát znak *.
v souboru s hosty:
2. Funguje pouze v nastavení "Režim root bez lokální VPN" (implikuje Režim DNS proxy bez lokální VPN).
Pokud totiž volbu "Režim root bez lokální VPN" vypnu program se tváří že běží, ale žádné blokování nefunguje a hlásí 0 connections. V logu nevidím žádné přidání iptables pravidel, jen pouze DNSFilterProxy running on 5300
Přehlédl jsem něco? Je nutné někde přenastavit DNS port manuálně?
Díval jsem se v lineageOS na Nastavení: Sít & Net : Rozšířené - sourkomé DNS:Vypnuto/AUto/Ručně: tam ale nelze vyplnit 127.0.0.1:5300... ani localhost:5300. A v případě localhost " mi nejde internet"
3. volba "Režim root bez lokální VPN" neumožňuje port 53 pro upstream server. Čím to? souvisí to s iptables pravidly?
rootModeOnAndroid = true|false - used by Android version.
# When dnsProxyOnAndroid is enabled, root mode will also open port 53 and route local DNS traffic to this.
# In root mode could also act as DNS filter Proxy within the local network.
# NOTE! this mode does not allow port 53 for upstream DNS Server
rootModeOnAndroid = false
v logu se totiž s touto volbou ukáže i
Hádám že to bude nějaká smyčka v iptables, kdy se autorovi nepodařilo zablokovat port 53 a zároveň použít pro upstream port 53 nebo to fakt technicky nejde? Nebo jiné vysvětlení? Ostatně myslím, že to by problém být neměl
(komentovaný cfg soubor) - je vhodné si otevřít vedle
Zde je obrázek s nastavením, ale je to starší screenshot, kde není volba "Povolit pouze požadavky lokálního proxy DNS". , ale to myslím, že mě netrápí, jelikož to jen přidá pravidla ip{6,}tables -A OUTPUT -p {udp,tcp}--dpt 53 -J DROP
Existuje nějaká alternativa?
Rekapitulace dotazů :
2. Proč to nefunguje v režimu DNSproxy bez rootu (bez volby "Režim root bez lokální VPN" ale s volbou "DNS proxy bez lokal VPN")
3.proč při provozu "Režim root bez lokální VPN" nelze mít upstream server na portu 53?
Bokem:
Funguje to i v souběhu s AdAway (což by měl být jen přechroustaný hosts soubor) - co je zablokováno v AdAway ani nejde do dns a neloguje se v personalDNSfiltru.
Mám k tomu několik postřehů a dotazů
1. WILDCARD domény
- hledaná vlastnost wildcard blokování mi funguje i bez nutnosti psát znak *.
v souboru s hosty:
Kód: [Vybrat]
# Add your own additional hosts here!
# Supports Blacklist, whitelist and map to custom IP
# Format for Blacklist: 1 host name per line (sample below).
# Wildcard Character "*" can be used for host blocking.
# Host name and all sub domains will be blocked.
sample4711.justasample.com- z toho jsem pochopil, že pro wildcard blokování je nutné zadat *.něco.com nebo *něco.com. Ale funguje to tak že i při zadání něco.com to blokuje i subdomény . Je to takto v pořádku? (Ačkoli takto se chová i dnsmasq)2. Funguje pouze v nastavení "Režim root bez lokální VPN" (implikuje Režim DNS proxy bez lokální VPN).
Pokud totiž volbu "Režim root bez lokální VPN" vypnu program se tváří že běží, ale žádné blokování nefunguje a hlásí 0 connections. V logu nevidím žádné přidání iptables pravidel, jen pouze DNSFilterProxy running on 5300
Přehlédl jsem něco? Je nutné někde přenastavit DNS port manuálně?
Díval jsem se v lineageOS na Nastavení: Sít & Net : Rozšířené - sourkomé DNS:Vypnuto/AUto/Ručně: tam ale nelze vyplnit 127.0.0.1:5300... ani localhost:5300. A v případě localhost " mi nejde internet"
3. volba "Režim root bez lokální VPN" neumožňuje port 53 pro upstream server. Čím to? souvisí to s iptables pravidly?
rootModeOnAndroid = true|false - used by Android version.
# When dnsProxyOnAndroid is enabled, root mode will also open port 53 and route local DNS traffic to this.
# In root mode could also act as DNS filter Proxy within the local network.
# NOTE! this mode does not allow port 53 for upstream DNS Server
rootModeOnAndroid = false
v logu se totiž s touto volbou ukáže i
Kód: [Vybrat]
iptables -t nat -A PREROUTING -p udp -dport 53 -j REDIRECT --to-port 5300Hádám že to bude nějaká smyčka v iptables, kdy se autorovi nepodařilo zablokovat port 53 a zároveň použít pro upstream port 53 nebo to fakt technicky nejde? Nebo jiné vysvětlení? Ostatně myslím, že to by problém být neměl
(komentovaný cfg soubor) - je vhodné si otevřít vedle
Zde je obrázek s nastavením, ale je to starší screenshot, kde není volba "Povolit pouze požadavky lokálního proxy DNS". , ale to myslím, že mě netrápí, jelikož to jen přidá pravidla ip{6,}tables -A OUTPUT -p {udp,tcp}--dpt 53 -J DROP
Existuje nějaká alternativa?
Rekapitulace dotazů :
2. Proč to nefunguje v režimu DNSproxy bez rootu (bez volby "Režim root bez lokální VPN" ale s volbou "DNS proxy bez lokal VPN")
3.proč při provozu "Režim root bez lokální VPN" nelze mít upstream server na portu 53?
Bokem:
Funguje to i v souběhu s AdAway (což by měl být jen přechroustaný hosts soubor) - co je zablokováno v AdAway ani nejde do dns a neloguje se v personalDNSfiltru.
59
Windows a jiné systémy / Android: blokace wildcard domén
« kdy: 05. 03. 2021, 22:10:29 »
Hledám určitý způsob blokování domén pro android.
Co ne:
-způsob hosts / Adaway je problematický v tom, že blokuje jen přesné hostnames a
-ublock origin : nevýhoda, že funguje jen v browseru.
Co ano:
- (klíčové) aby to umělo wildcard matchování: aby pro blokaci a.b.com a b.b.com stačilo napsat b.com
- (advanced) - aby to umělo adservice.google.*
-bonus : passthrough pro hotspot funkci (tzn aby zařízení připojená přes wifi nebo USB hotspot při využití DNS hotspotu
měly aplikovanou stejnou filtraci)
Samozřejmě rozumím způsobu+principu DNS vs hosts VS VPN (ta třetí možnost lokální VPN, ale o tom nic nevím a mám předsudek že je to nevýkonné). :
- že blokace dle DNS funguje jen, když se je ptáno toho DNS, když se ptá jiného DNS, tak je to vniveč
- že hosts blokace fungujuje jen při "místním systémovém" zjišťováním gethostbynameatd() a že neumí wildcard
A aby tu fungovalo na jakékoli síti (různé wifi, mobilní data).
Jaké řešení tedy zvolit? Je jasné, že když aplikace bude komunikovat s vlastním DNS (ledaže by byl port 53 blokován) nebo byl překlad v aplikaci natvrtdo, s tím holt nic udělat nejde.
Vychází mi z toho něco jako místní "hosts-like" chování, tzn i když z DHCP přijde jakýkoli DNS server, tak aby lokální překlad fungoval přes nějaký lokální DNS, který ovšem umí wildcard.
Tzn Local VPN se mi nepozdává (pokud tam není nějaká feature, že přes VPN jde pouze port 53) a hosts-file má omezení wildcard.
Někde na slant.com jsem viděl srování těchto nástrojů :
https://www.slant.co/topics/4567/~ad-blockers-for-android
Je tam něco takového, co hledám? Jaký směr řešení by byl správný? něco, co nějak pro každé připojení k síti například automagicky přepíše DNS server na 127.0.0.1? Je něco takového v provozu?
A nebo zatracuji VPN řešení blokace zbytečně? Jak se snese s dalším VPN? Jde řetězit? Jde přes VPN vše nebo jen DNS volitelně?
Co ne:
-způsob hosts / Adaway je problematický v tom, že blokuje jen přesné hostnames a
-ublock origin : nevýhoda, že funguje jen v browseru.
Co ano:
- (klíčové) aby to umělo wildcard matchování: aby pro blokaci a.b.com a b.b.com stačilo napsat b.com
- (advanced) - aby to umělo adservice.google.*
-bonus : passthrough pro hotspot funkci (tzn aby zařízení připojená přes wifi nebo USB hotspot při využití DNS hotspotu
měly aplikovanou stejnou filtraci)
Samozřejmě rozumím způsobu+principu DNS vs hosts VS VPN (ta třetí možnost lokální VPN, ale o tom nic nevím a mám předsudek že je to nevýkonné). :
- že blokace dle DNS funguje jen, když se je ptáno toho DNS, když se ptá jiného DNS, tak je to vniveč
- že hosts blokace fungujuje jen při "místním systémovém" zjišťováním gethostbynameatd() a že neumí wildcard
A aby tu fungovalo na jakékoli síti (různé wifi, mobilní data).
Jaké řešení tedy zvolit? Je jasné, že když aplikace bude komunikovat s vlastním DNS (ledaže by byl port 53 blokován) nebo byl překlad v aplikaci natvrtdo, s tím holt nic udělat nejde.
Vychází mi z toho něco jako místní "hosts-like" chování, tzn i když z DHCP přijde jakýkoli DNS server, tak aby lokální překlad fungoval přes nějaký lokální DNS, který ovšem umí wildcard.
Tzn Local VPN se mi nepozdává (pokud tam není nějaká feature, že přes VPN jde pouze port 53) a hosts-file má omezení wildcard.
Někde na slant.com jsem viděl srování těchto nástrojů :
https://www.slant.co/topics/4567/~ad-blockers-for-android
Je tam něco takového, co hledám? Jaký směr řešení by byl správný? něco, co nějak pro každé připojení k síti například automagicky přepíše DNS server na 127.0.0.1? Je něco takového v provozu?
A nebo zatracuji VPN řešení blokace zbytečně? Jak se snese s dalším VPN? Jde řetězit? Jde přes VPN vše nebo jen DNS volitelně?
60
Windows a jiné systémy / Android Chrome - nepříjemný reload stránky při přepnutí / odemknutí
« kdy: 03. 03. 2021, 20:38:11 »
Nazdar, vadí mi hodně v prochlížeči chrome v androidu(9) jedna věc, když mám puštěno přehrávání videostreamu (pořadu, youtube, nejspíš i podcastú. Když se přepnu do jiné aplikace nebo zamknu(omylem) klávesnici("pohotovostní režim"?) ale s vyjímkou timeoutu automatického zámku kdy kupodivu to zůstane bez reloadu , na plochu a pak zpátky, stane se věc která mě šíleně vytočí:stránka se zastaví a po přepnutí zpět do prohlížeče se reloadne
Děje se to i když si daný video prvkek "dám na celou obrazovku" : po minimalizaci je vše OK, video hraje mohu spustit aplikaci.
Taky se semi stalo to,, že po zamknutí obrazovky a odemčení se mi přímo v tom obdélníčku najednou ukázal horní okraj chromu (Tlačítko domečku, tlačítko indikátor https, "1" v obdélníku a vertikální trojtečka na prvním řádku, pod tím progressbar a pod tím bílá plocha - plocha stránky)
Tak když video je na celé obrazovce a je pauznuté, tak vždy dojde k zastavení (a následně k reloadu). Ale jakou do má do psích kulí logiku, když tedy video minimalizují , když hraje a následně dám pauzu přes "menu notifikací" – pak k zastavení nedojde.
Teď se to ale zase zastavilo - když jsem si video pauznul a obrazovka zastavila. Je to fakt nekonzistentní.!
Pak by mě zajímal jeden detail: minimalizované video má šířku poloviny obrazovky, což je fakt nedostačující. Když ale na ten obdélníček kliknu, tak se dočasně zvětší skoro na celou šířku (i tak to není žádná hitparáda kvůli 16:9 nudlovitosti: asi 16/81 plochy) – to ale funguje jen proto, abych následně mohl druhým kliknutí na objevivší se bílý "terčík" přepnout do chromu na to fullscreen zobrazení videa , když kliknu jinam, zase se zmenší na půlku šířky ( takže z 16/81 na 4/81 ... 5% plochy obrazovky!!!)
Jak tedy donuti chromajzla na androjzlovi, aby běžící video, potažmo webstránky se "nezastavily" a po přepnutí zpět do chromu se nereloadovaly??? Ani u videa to není stoprocentní!!!
Děje se to i když si daný video prvkek "dám na celou obrazovku" : po minimalizaci je vše OK, video hraje mohu spustit aplikaci.
Taky se semi stalo to,, že po zamknutí obrazovky a odemčení se mi přímo v tom obdélníčku najednou ukázal horní okraj chromu (Tlačítko domečku, tlačítko indikátor https, "1" v obdélníku a vertikální trojtečka na prvním řádku, pod tím progressbar a pod tím bílá plocha - plocha stránky)
Tak když video je na celé obrazovce a je pauznuté, tak vždy dojde k zastavení (a následně k reloadu). Ale jakou do má do psích kulí logiku, když tedy video minimalizují , když hraje a následně dám pauzu přes "menu notifikací" – pak k zastavení nedojde.
Teď se to ale zase zastavilo - když jsem si video pauznul a obrazovka zastavila. Je to fakt nekonzistentní.!
Pak by mě zajímal jeden detail: minimalizované video má šířku poloviny obrazovky, což je fakt nedostačující. Když ale na ten obdélníček kliknu, tak se dočasně zvětší skoro na celou šířku (i tak to není žádná hitparáda kvůli 16:9 nudlovitosti: asi 16/81 plochy) – to ale funguje jen proto, abych následně mohl druhým kliknutí na objevivší se bílý "terčík" přepnout do chromu na to fullscreen zobrazení videa , když kliknu jinam, zase se zmenší na půlku šířky ( takže z 16/81 na 4/81 ... 5% plochy obrazovky!!!)
Jak tedy donuti chromajzla na androjzlovi, aby běžící video, potažmo webstránky se "nezastavily" a po přepnutí zpět do chromu se nereloadovaly??? Ani u videa to není stoprocentní!!!
