[forum] Gele balk voor nieuwe berichten werkt niet meer

[Dragor]

De gele balk die onderaan een topic komt als er een nieuw bericht is geplaatst werkt bij mij niet meer voor geen enkel topic.

Ik merkte dit gistermiddag voor het eerst, gistermorgen werkte het nog wel.

Het lijkt erop dat dit niet voor iederen het geval is, maar dat ik niet de enige ben:

• Dido in "De Devschuur Coffee Corner - Iteratie 6"
• dcm360 in "De Devschuur Coffee Corner - Iteratie 6"

Platform: Windows 7
Browser: Chrome Version 35.0.1916.114 m
Extensions: AdBlock (Disabled voor Tweakers.net), colorPicker 0.9, Google chrome to phone, IE Tab
Proxy: Ja

[Thomas]

Hier zelfde verhaal.

Ook W7, Chrome versie 35.0.1916.114 m, ABP disabled voor T.net (voor de rest geen extensies aan staan).

[naaitsab]

Hier ook, problemen met de balk.
Windows 8.1 Enterprise Update 1
Chrome 35.0.1916.114 m
Geen extensies actief op GoT.

Thuis kwam de balk ook niet naar voren, zelfde Chrome versie alleen Windows 7 SP1.

[Verwijderd]

Hier werkt het gewoon.

Windows 8
Firefox 30B9
Extenties ABP (uit op t.net domein), Firebug (op het moment van schrijven deactivated) en Stylish.

[tomcool]

Hier werkt hij ook niet.

Chrome versie 35.0.1916.114 m
geen extensies

[PromWarMachine]

Werkt hier prima.

Windows 7 SP1
Firefox 29.0.1

[Kees]

Werkt hier ook goed met Firefox onder linux

Maar zo te zien doet chrome totaal geen xmlhttp requests als ik hem open laat staan.. Ik maak er een tocket voor

[ Voor 134% gewijzigd door Kees op 04-06-2014 11:44 ]

[.oisyn]

Maar zo te zien doet chrome totaal geen xmlhttp requests als ik hem open laat staan

Hier wel, meest recente Chrome release

Version 35.0.1916.114 m om precies te zijn.

[ Voor 15% gewijzigd door .oisyn op 04-06-2014 12:20 ]

[Memphisto]

Werkt hier prima.
Chrome versie 35.0.1916.114 m

[Cloud]

Werkt hier ook niet. Voor mijn gevoel sinds deze week.
Specs:

code:

Windows 7 Enterprise 64-bit SP1
35.0.1916.114 m
Wel APB+ geïnstalleerd, maar staat uit op *.tweakers.net

Chrome geeft aan dat het de meest recente release versie is.

[dcm360]

Ook stuk hier in Opera 12. Geen requests, ook geen javascript-errors in de debugger.

Edit: Ook geen updates op de frontpage, en de tracker update ook niet.

Volledige versie: Opera/9.80 (X11; Linux x86_64) Presto/2.12.388 Version/12.16

[ Voor 48% gewijzigd door dcm360 op 04-06-2014 13:08 ]

[Verwijderd]

Ook hier geen gele balk, lijkt niet Chrome 35 te liggen, heb op dit moment versie 33.0.1750.154 m op Windows8.1. Geen extenties.

Edit: Heb het idee dat het stuk sinds de aankonding van de release van iteratie #52.
Edit2: Wat dmc360 zegt, ook geen update van de tracker en ook geen notificatie in de tabtitels.

[ Voor 43% gewijzigd door Verwijderd op 04-06-2014 13:30 ]

[PromWarMachine]

Dragor schreef op woensdag 04 juni 2014 @ 10:48:
De gele balk die onderaan een topic komt als er een nieuw bericht is geplaatst werkt bij mij niet meer voor geen enkel topic.

Ik merkte dit gistermiddag voor het eerst, gistermorgen werkte het nog wel.

Dit klinkt natuurlijk heel erg alsof het te maken heeft met de standaard releasedag van Tweakers. De dinsdagmorgen.

Daarvoor zouden ze in hun versiebeheer systeem moeten duiken. In de .plan stond weinig concreets waar wij ze mee kunnen helpen.

[Untouchablezz20]

Hier ook last van. Geen gele balk bij een nieuw bericht en geen (1) in de titel als aanduiding.

Mac OS X 10.9.3
Safari 7.0.4

[ Voor 9% gewijzigd door Untouchablezz20 op 04-06-2014 13:31 ]

[OkkE]

Hier ook geen balk of “(1)” in de titel.

iMac OS X 10.9.2
Chrome 35.0.1916.114

[Maverick]

Hier hetzelfde probleem. Zowel met chrome op de desktop als op de tablet.

[RobIII]

Ten overvloede waarschijnlijk: hier ook stuk.

Chrome v35.0.1916.114 m
Wel een stapeltje extensions (waaronder ABP, maar uitgeschakeld op T.net (en "abo" )) maar weinig dat er mee te maken zou (kunnen) hebben.

[Dido]

Hier doet ie het weer - vanochtend was ie nog stuk, na een power outage werkt het weer. Misschien als iedereen even zijn computer uit en weer aan zet?

[crisp]

We worden gebeten door deze bug in Chrome: https://code.google.com/p/chromium/issues/detail?id=230705

workaround is in de maak

[crisp]

En zou weer moeten werken

[.oisyn]

Nou ja, "workaround", de t.net codebase lijkt me sowieso een bug te bevatten, want een setTimeout() zal in Chrome nooit hetzelfde id meegeven als een setInterval(), en id's worden ook niet hergebruikt.

[crisp]

.oisyn schreef op woensdag 04 juni 2014 @ 15:31:
Nou ja, "workaround", de t.net codebase lijkt me sowieso een bug te bevatten, want een setTimeout() zal in Chrome nooit hetzelfde id meegeven als een setInterval(), en id's worden ook niet hergebruikt.

Chrome behandeld clearInterval(true) hetzelfde als clearTimeout(1), dus dat is wel degelijk een bug.

[.oisyn]

https://developer.mozilla.../API/Window.clearInterval

Wat zou clearInterval(true) dan volgens jou moeten doen?

[crisp]

.oisyn schreef op woensdag 04 juni 2014 @ 15:47:
https://developer.mozilla.../API/Window.clearInterval

Wat zou clearInterval(true) dan volgens jou moeten doen?

Niets, want true is geen geldige identifier. En daarnaast zou clearInterval geen timeout mogen clearen.

[.oisyn]

Luister, ik zeg niet dat Chrome geen bug bevat. Ik zeg dat als je eigen code geen bugs bevat je nooit tegen de Chrome bug aanloopt . Aangezien GoT dat wel doet zit er dus een bug in de code. Dat andere browsers daar geen last van hebben betekent nog niet dat de API correct gebruikt wordt.

Je zegt dat je een "workaround" hebt moeten maken. Maar op het moment dat je clearInterval() nooit een identifier meegeeft die niet eerder uit setInterval() is gekomen, (en vice versa voor *Timeout()), dan zul je nooit last hebben van de bug in Chrome. Dus blijkbaar wordt de API ergens verkeerd gebruikt in de GoT codebase .

[ Voor 59% gewijzigd door .oisyn op 04-06-2014 16:04 ]

[dcm360]

Leuk dat het op een een bug in Chrome wordt afgeschoven... In ieder geval, in Opera werkt het ook weer.

[crisp]

Feitelijk deden wij dit in onze code:

JavaScript:

var refreshTimer = setTimeout(refreshFunc, 1000);

// ergens in een ander codepath
var domLoadedPollCheck = needsPolling ? setInterval(pollFunc, 50) : true;

// als domContentLoaded getriggered wordt
clearInterval(domLoadedPollCheck); // will be ignored if this is not a valid interval identifier

Nu heb ik feitelijk zelf een check moeten inbouwen om te kijken of 'domLoadedPollCheck' wel een interval id is of niet omdat Chrome dat in zijn implementatie niet doet terwijl dat wel zou moeten, en intervals en timeouts niet gescheiden heeft.

Dit dus:

JavaScript:

if (domLoadedPollCheck !== true)
    clearInterval(domLoadedPollCheck);

dcm360 schreef op woensdag 04 juni 2014 @ 16:05:
Leuk dat het op een een bug in Chrome wordt afgeschoven... In ieder geval, in Opera werkt het ook weer.

Nogal logisch aangezien Opera tegenwoordig dezelfde codebase gebruikt als Chrome...

[dcm360]

Opera 12 niet.

crisp schreef op woensdag 04 juni 2014 @ 16:15:
[...]

Da's antiek

Probeer maar eens een nieuwere Opera voor Linux te krijgen dan...

[ Voor 93% gewijzigd door dcm360 op 04-06-2014 16:16 ]

[crisp]

dcm360 schreef op woensdag 04 juni 2014 @ 16:14:
Opera 12 niet.

Da's antiek

[Douweegbertje]

crisp schreef op woensdag 04 juni 2014 @ 15:43:
[...]

Chrome behandeld clearInterval(true) hetzelfde als clearTimeout(1), dus dat is wel degelijk een bug.

Aan jouw kant
Dat iets heeft gewerkt, wilt nog niet zeggen dat het geen bug bevat. Zie het maar als een dubbele bug, waarbij de browser het nu technisch gezien fatsoenlijk doet, en daarom de code niet meer werkt

[Kees]

.oisyn schreef op woensdag 04 juni 2014 @ 15:47:
https://developer.mozilla.../API/Window.clearInterval

Wat zou clearInterval(true) dan volgens jou moeten doen?

Douweegbertje schreef op woensdag 04 juni 2014 @ 16:19:

Zie het maar als een dubbele bug, waarbij de browser het nu technisch gezien fatsoenlijk doet, en daarom de code niet meer werkt

Als ik die API zo lees dan moet clearInterval bij een ongeldige identifier een waarschuwing of error geven. Het is een bug dat hij dan een identifier bedenkt en die cleared.

Het begint zo wel steeds meer op php te lijken

[ Voor 21% gewijzigd door Kees op 04-06-2014 16:25 ]

[.oisyn]

crisp schreef op woensdag 04 juni 2014 @ 16:13:
Nu heb ik feitelijk zelf een check moeten inbouwen om te kijken of 'domLoadedPollCheck' wel een interval id is of niet omdat Chrome dat in zijn implementatie niet doet

Dat is een aanname die je maakt. Daar lees ik in de specs niets over terug. Sterker nog, de specs zeggen niet eens dat er twee aparte lijsten zijn, maar dat er "a list of timers" is.

Each object that implements the WindowTimers interface has a list of active timers. Each entry in this lists is identified by a number, which must be unique within the list for the lifetime of the object that implements the WindowTimers interface.

The clearTimeout() and clearInterval() methods must clear the entry identified as handle from the list of active timers of the WindowTimers object on which the method was invoked, if any, where handle is the argument passed to the method. (If handle does not identify an entry in the list of active timers of the WindowTimers object on which the method was invoked, the method does nothing.)

Ik vraag me dus sterk af of dat wat Chrome doet überhaupt wel de standaard tegenspreekt.

Kees schreef op woensdag 04 juni 2014 @ 16:24:
[...]

[...]


Als ik die API zo lees dan moet clearInterval bij een ongeldige identifier een waarschuwing of error geven. Het is een bug dat hij dan een identifier bedenkt en die cleared.

Ik vind het knap dat je dat uit die summiere tekst haalt eerlijk gezegd...

[ Voor 46% gewijzigd door .oisyn op 04-06-2014 16:29 ]

[crisp]

Dan lees ik de spec anders dan jij:

window . clearInterval( handle )

Cancels the timeout set with setInterval() identified by handle.

Dus zou geen timeout moeten cancellen die niet met setInterval is aangemaakt (maar met setTimeout).

en:

(If handle does not identify an entry in the list of active timers of the WindowTimers object on which the method was invoked, the method does nothing.)

Boolean true is geen handle want setTimeout/setInterval geven dat niet terug, die geven integers terug.

[Douweegbertje]

Kees schreef op woensdag 04 juni 2014 @ 16:24:
[...]

[...]


Als ik die API zo lees dan moet clearInterval bij een ongeldige identifier een waarschuwing of error geven. Het is een bug dat hij dan een identifier bedenkt en die cleared.

Het begint zo wel steeds meer op php te lijken

Dat kan, maar dan nog is je code niet goed. Als ik de snippet zo even lees, is het gewoon random of de identifier is geset. Dat is de fout in eerste instantie. Je hebt gelijk dat het nogal een triviale functie is "maar" het is enigszins bekend dat sommige browsers dezelfde codeset gebruiken voor zowel interval als timeout.

Mooie quote

Sure, some browsers may very well share the same code to clear intervals and timeouts the same way, but does not mean they are interchangeable and you are most certainly not guaranteed that they would work the same across all browser implementations.

In elk geval, je code is random en dat zou je moeten afvangen. Als dat er al standaard was zoals (neem het niet te letterlijk)

JavaScript:

if(needsPolling)
{
 //interval
 // clear interval (of set een var op true, dat je het later kan doen..)
}

Dan was er niets aan de hand.

Nu is het gewoon random wat de waarde kan zijn.

_{geeft overigens niet weg dat het naar mijn mening bad practise is hoe de code van Chrome is hoor en heel logisch is het niet, maar daarom maak je de code juist robuust..}

[Dragor]

Wat de spec ook mag zeggen en de browsers ook mogen doen. Mijn wijsvinger (en F5 knop) bedankt jullie voor de snelle oplossing.

[Douweegbertje]

Dragor schreef op woensdag 04 juni 2014 @ 16:46:
Wat de spec ook mag zeggen en de browsers ook mogen doen. Mijn wijsvinger (en F5 knop) bedankt jullie voor de snelle oplossing.

Tja, niet iedereen valt onder het kopje:

[Dido]

Als ie het niet doet in IE6, moet ik dat dan ook melden?

[Thomas]

Thomasx4 schreef op woensdag 04 juni 2014 @ 11:05:
Hier zelfde verhaal.

Ook W7, Chrome versie 35.0.1916.114 m, ABP disabled voor T.net (voor de rest geen extensies aan staan).

Balk werkt weer hier!

[crisp]

Dragor schreef op woensdag 04 juni 2014 @ 16:46:
Wat de spec ook mag zeggen en de browsers ook mogen doen. Mijn wijsvinger (en F5 knop) bedankt jullie voor de snelle oplossing.

En daar gaat het om, case closed dus wmb

Dido schreef op woensdag 04 juni 2014 @ 16:58:
Als ie het niet doet in IE6, moet ik dat dan ook melden?

Nee, IE6 supporten wij al lang niet meer

[.oisyn]

crisp schreef op woensdag 04 juni 2014 @ 16:29:
Dus zou geen timeout moeten cancellen die niet met setInterval is aangemaakt (maar met setTimeout).

Als je heel pedantisch wil zijn is dat niet wat er staat. Er staat alleen wat ie wel doet, niet wat ie niet zou moeten doen

Boolean true is geen handle want setTimeout/setInterval geven dat niet terug, die geven integers terug.

Da's een redenatie van niets. De tekst heeft het over een handle, daaruit blijkt niet of dat per se een int moet zijn. De interface definitie spreekt weliswaar expliciet over long, maar doet dat ook voor clearTimeout() en clearInterval(). Er staat niet bij wat er gebeurt als je iets meegeeft dat geen long is.

.edit: Eigenlijk is het gewoon heel duidelijk. Web IDL definieert dat een boolean true wordt geconverteerd naar 1.

quote: http://heycam.github.io/webidl/#es-long

4.2.8. long

An ECMAScript value V is converted to an IDL long value by running the following algorithm:

1. Initialize x to ToNumber(V).
[..]

quote: http://people.mozilla.org...6-draft.html#sec-tonumber

7.1.3 ToNumber

The abstract operation ToNumber converts its argument to a value of type Number according to Table 11:
[..]
Boolean Return 1 if argument is true. Return +0 if argument is false.

clearInterval(true) is dus identiek aan clearInterval(1), en dat is duidelijk niet wat je wilt doen hier

Gelukkig is deze verschikkelijke bug nu gefixed

[ Voor 31% gewijzigd door .oisyn op 04-06-2014 18:32 ]

[crisp]

Zelfs dan nog verwacht ik niet dat een clearInterval een timeout kan cancellen. Juist om dergelijk onverwacht gedrag te voorkomen is het belangrijk dat dergelijke API's consistent door browserbouwers worden geinterpreteerd. Bij twijfel is een strictere benadering dan ook te prefereren boven een lossere tenzij daar goede redenen voor zijn (en dan zou de specificatie daarop aangepast moeten worden).

Overigens is het mij niet duidelijk waar in IDL type conversion kan plaatsvinden en waar niet. Dat handle een positief integer is blijkt overigens uit de timer initialization steps (nummertje 2)