BUG: Chrome for Android: Lukkede faner gjenopprettes

[jpg]

Bug i Chrome: Lukkede faner gjenopprettes (a href target relatert)

Gjelder Android versjon 5.0.2 men senere også påvist i 4.4.4. Uvisst hvor mange Android versjoner det faktisk er snakk om.

 

Feilen er ihvertfall tilstede i Chrome for Android v.42.0, men også her er jeg usikker på hvor mange versjonsnumre tilbake i tid det hele går.

 

Jeg utelukker ikke at dette er en Blink-bug, og dermed gjeldende for flere nettlesere.

Blink v.537.36

 

---

Litt teknisk bug rapport, så håper noen har litt HTML forståelse.

 

Når jeg klikker meg inn på en lenke, som (er meningen at) skal åpnes i et nytt vindu, åpnes denne selvfølgelig som forventet i nytt vindu. Dette gjøres slik:

<a target="_blank" href="http://example.com/">Lenke åpnes i nytt vindu</a>

Når jeg vil at en lenke skal åpnes i et eksisterende (evt. nytt spesifikk) vindu, gjøres det slik:

<a target="mywindow" href="http://example.com/">Lenke som skal åpnes i "Mitt Vindu"</a>

For å fjerne evt. usikkerhetsmomenter:

Når du klikker på en lenke (metode 2) skal den nye adressen erstatte en evt eksisterende adresse. F.eks. Artikkel B lastes inn og erstatter Artikkel A (som du åpnet 1 minutt tidligere).

Hvis derimot ingen "mywindow" lenker er åpnet, åpnes det et tilsynelatende nytt vindu.

 

Fremgangsmåte:

• Artikkel #1
  • Klikk på lenken som åpnes i et tilsynelatende nytt vindu ("mywindow")
  • Lenken åpnes, du leser f.eks. artikkelen
  • Du lukker siden, ved å trykke tilbake knappen
  • Siden er lukket, og du er tilbake til utgangspunktet
• Artikkel #2
  • Repetisjon av steg 1.1 -> 1.4
• Hvis bug skjer dette istedet:
  • Klikk på lenken som åpnes i et tilsynelatende nytt vindu ("mywindow")
  • Lenken åpnes, du leser f.eks. artikkelen
  • Du forsøker å lukke siden med tilbakeknappen, men istedet åpner en gammel artikkel seg (en du leste og lukket for noen minutter siden)
  • Du lukker siden, ved å trykke tilbake knappen (denne gangen fungerer det)
  • Siden er lukket, og du er tilbake til utgangspunktet
• Artikkel nr. *uendelig*
  • Repetisjon av steg 1.1 -> 1.4 evt ved bug 3.1 -> 3.5

Foreløpig vet jeg ikke om så mange steder å gjenskape feilen, men har hendt meg et 20-talls ganger på denne adressen. http://vipnytt.no/siste/it.

 

Jeg har personlig skrevet all relatert HTML og jQuery kode på adressen, og kan skrive under på at kildekoden ikke har blitt endret på over 3/4 dels år minst. Koden har vist seg å være feilfri helt til nå ca 1-2 uker siden.

 

Off topic:

 

I Chrome for Android 5.0 (og nyere) hvor er lukk alle faner knappen? Fanene har blitt flyttet ut av Chrome, og vises som individuelle Android apper, men hva gjør man når man har vært inne på 20 nettsider og 10 apper? Alle må individuelt sveipes bort, altså sveipe fingeren over skjermen 30 ganger bare for å gjøre det man før kunne ved hjelp av 2stk touch trykk!!!

 

[xibriz]

Pro tip: Ikke gjenbruk "mywindow", men lag ett unikt navn. F.eks. sleng på en timestamp eller ID til artikkelen eller noe.

Endret 13. april 2015 av xibriz

[jpg]

Ja, forstår veldig godt hvorfor du sier det, men da forsvinner dessverre hele vitsen, ihvertfall med ID.

 

Bruker jeg timestamp, er jeg tilbake til utgangspunktet, da feilen oppstår når jeg har klikket på flere lenker (og lukket de en etter en etter hvert), og det uten å oppdatere siden.
 
Samme nettsiden er laget både for mobil, nettbrett og PC, kildekoden er identisk.
Da jeg bruker frames på desktop utgaven, er jeg nødt til å bruke et og samme identifiserende navn.
 
Desktop/tablet: åpnes i frameset/frame
Mobil: Frameset skjult, og lenken åpnes derfor i nytt vindu.
 
Derfor er det designet slik:
Hvis du har en ca 8-tommer tablet, vil denne vises som mobil i stående posisjon, men desktop i liggende. Lenkene må derfor fungere med begge løsningene.

 

---

Uansett, rett på sak:
Når et vindu er lukket i Chrome (for Android), skal ikke det vinduet åpne seg igjen, uansett hvor mange ganger du refererer til vinduet.
Eksisterer vinduet -> Bruk det på nytt
Mangler vinduet -> Lag et nytt
 
Fra W3C: http://www.w3.org/TR/html401/present/frames.html#target-info

16.3.2 Target semantics
User agents should determine the target frame in which to load a linked resource according to the following precedences (highest priority to lowest):

• If an element has its target attribute set to a known frame, when the element is activated (i.e., a link is followed or a form is processed), the resource designated by the element should be loaded into the target frame.
• If an element does not have the target attribute set but the BASE element does, the BASE element's target attribute determines the frame.
• If neither the element nor the BASE element refers to a target, the resource designated by the element should be loaded into the frame containing the element.
• If any target attribute refers to an unknown frame F, the user agent should create a new window and frame, assign the name F to the frame, and load the resource designated by the element in the new frame.

 

Punkt 1: En frame som er lukket, er ikke lenger en del av nettleseren eller brukeropplevelsen. Punktet er derfor ikke relevant. Det er her feilen i Chrome ligger. På en eller annen måte, har ikke Chrome tømt hurtigbufferet tilhørende gamle vinduer.

Punkt 2 og 3 kan simpelt ignoreres, da det ikke er tilfelle i denne saken.

Punkt 4: Dette er hva Chrome skal gjøre, åpne en ny frame. Dette er det som er forventet (men ikke alltid) skjer.

Endret 13. april 2015 av jpg