Cosa succede quando posiziono il mouse su un collegamento in Chrome?

Quando questo link ( http://a//%%30%30 ) viene cliccato in Google Chrome, Chrome interrompe e chiude tutte le tabs e le istanze.

Ma in alcuni casi ho solo bisogno di spostare sopra il collegamento e la scheda si blocca.

Cosa succede quando posso spostare su questo collegamento? Voglio dire, cosa fa Chrome quando un collegamento è stato superato?

L'arresto è dovuto a un bug riscontrato di recente in Chrome – e altri browser WebKit (!) * – specificamente correlati a %%30%30 , %0%30 o %%300 come parte dell'URL, che internamente finiscono che rappresenta lo stesso simbolo: null . Potete leggere di più sul bug qui .

Non è un bug che riguarda la maggior parte dei collegamenti, in modo da non wherete preoccuparvi di spostarsi sopra i collegamenti.

Gli appunti:
* Gli altri browser WebKit includono Safari, Opera, Browser a vapore, Midori, S60 (Symbian), Browser Blackberry e browser di Playstation 3 – ma non Firefox, Internet Explorer o Edge.

Modifica: questo errore è stato ora risolto in Chrome 45.0.2454.101 come Deltik indica.

Di più su cosa succede

Il problema è correlato al canonicalizer URL , che viene eseguito non appena si posiziona sopra un collegamento, forse per visualizzare il collegamento nella barra di stato del browser e per preimpostare la pagina web in modo che carichi più velocemente una volta cliccato.

Per quanto riguarda il ruolo del canonicalizer URL:
Quando un URL è scritto in HTML , può essere scritto in un module come /home o ../../home , ma i browser devono tradurre questo URL a qualcosa con un protocollo e un dominio, ad esempio http://superuser.com/home . Inoltre l'URL può contenere Escapes URL che devono essere tradotti e queste fughe sono codificate per cento , come %%30%30 . (Un elenco più completo di URL escapisce qui ).
La funzionalità che gestisce questa traduzione URL è ciò che finisce per arrestare, perché riceve gli input che gli sviluppatori non si aspettano / gestiscono.

Ecco un riepilogo della modifica di codice che ha risolto il problema:

Gestire correttamente le sfuggite nidificate problematiche nei routes URL.

In modo specifico, se l'inversione nell'ingresso port all'URL di output contenente una nuova sequenza escaped, ad esempio convertire l'ingresso "%% 30% 30" in "% 00", uscire dal leader '%' come "% 25" per assicurare l'output la sequenza non viene trattata come una nuova sequenza di escape valida.

Ciò assicura che la canonicalizzazione dello stesso URL una seconda volta non apporti modifiche, che è importnte per evitare incidenti e altri bug in una varietà di luoghi in entrambi i templates di debug e rilascio.

Come afferma Fabio Turati,

Quando si passa sopra un collegamento, Chrome viene visualizzata nell'angolo in basso a sinistra. Ciò richiede una certa elaborazione, compresa la "traduzione" di caratteri particolarmente codificati.

Tuttavia, dal tuo post e commento penso che tu sia più preoccupato se Chrome si connette al link in background. Lo fa , così fanno altri browser moderni ( Firefox , Opera ). Puoi distriggersre il prefetching nelle preferenze di Chrome o installare uBlock Origin per get ulteriori impostazioni di protezione .

Volevo dare ulteriori chiarimenti su ciò che esattamente accade qui.

In sostanza,% 30 è un URL codificato 0 e% 00 è un URL NULL codificato (che viene visualizzato in binario come 0000 0000). Quindi, se si dispone di un URL che ha un carattere codificato annidato che decodifica a NULL, si verifica il problema.

Chrome effettua quanto segue quando canonizza un URL (fonte: https://code.google.com/p/chromium/issues/detail?id=533361#c13 ):

  • Una string di ingiunzione "http: //a.com/%%30%30" viene distriggersta a " http://a.com/%00 " e considerata una valida GURL.
  • Questa GURL viene infine inviata a GURLToDatabaseURL () che denomina ReplaceComponents () su di esso per eliminare il nome utente e la password.
  • ReplaceComponents () ri-canonizza l'URL.
  • La canalizzazione del path colpisce la sequenza "% 00", si distriggers, vede che si tratta di un carattere 0 che non è valido negli URL, lo lascia sfuggire, ma contrassegna l'URL risultante come non valido.
  • Una volta tornato a GURLToDatabaseURL (), chiama .spec () sul nuovo URL, aspettandolo valido, poiché l'URL di input è stato garantito valido e abbiamo semplicemente rimosso il nome utente e la password. Questo DCHECKs.

Quindi l'URL viene prima considerato valido, ma dopo aver rimosso alcuni dati privati, viene invalidato. Tuttavia, dopo che questi dati vengono rimossi, la function che ha chiamato quel particolare codice prevede un URL valido.

Una parte del motivo per cui questo URL è considerato non valido è perché NULL è utilizzato in un numero di vecchi software e lingue per indicare la fine di una string (perché è fondamentalmente 8 zero in una row che è facile da individuare per un computer).