Error con los iconos de formato

Utilizando Firefox me he dado cuenta que desde hace un tiempo hay un error en el foro que me impide ver los iconos de formato (no sé explicar muy bien cuáles son).
He borrado mi caché, las cookies y demás, pero sigue sin mostrarse nada, ilustro con capturas:

Creando este mismo post:
Imagen

Panel de control:
Imagen

Parece una tontería pero resulta bastante incómodo a la hora de utilizar los botones para dar formato a los mensajes (he de dejar el ratón por encima para saber qué hace cada botón [qmparto] )

No sé si el problema es solo mío, pero lo dudo.
Un beso.

Edito: Por curiosidad he entrado a EoL desde Google Chrome y desde Chrome lo veo todo correcto, solo falla Firefox.
@Naifus

Yo uso Firefox en W7 64-bits y lo veo perfectamente:

Imagen


Igual es cosa de la codificación de texto que tienes predeterminada o del zoom, ... por apuntar alguna posibilidad.
Sé que me repito más que el ajo, pero ¿has probado desactivando todas las extensiones?
melado escribió:Sé que me repito más que el ajo, pero ¿has probado desactivando todas las extensiones?


Coño, qué tonto soy [facepalm], no se me había ocurrido eso [qmparto]

He ido desactivando una a una, resulta que la conflictiva era la extensión https everywhere.

¡Gracias por ayudarme con el problema! [tadoramo]
Pero eso no debería fallar así... los iconos que usamos son descargables por HTTP y por HTTPS:

http://netdna.bootstrapcdn.com/font-awe ... f2?v=4.3.0
https://netdna.bootstrapcdn.com/font-aw ... f2?v=4.3.0

:-?
Pues por algún motivo, me es imposible de visualizarlos mientras tenga esa extensión puesta.
¿Has probado a ponértela a ver si te pasa también?

Edit: En Google Chrome también tenía puesta esa extensión y veía correctamente los iconos, ahora no sé si es un error de mi navegador, de la extensión o de la web :-?
melado escribió:Pero eso no debería fallar así... los iconos que usamos son descargables por HTTP y por HTTPS:

http://netdna.bootstrapcdn.com/font-awe ... f2?v=4.3.0
https://netdna.bootstrapcdn.com/font-aw ... f2?v=4.3.0

:-?


Pues créete que falla por eso. Y no lo digo yo, lo dice la gente que lo confirma teniendo esa extensión instalada:

hilo_iconos-raros-en-eol-al-escribir-mensajes_2154529

De cualquier manera, yo lo confirmo al forzar el permiso HSTS de forma manual, sin extensiones.

Sea lo que sea que impide su carga, Gecko dice, cuando se fuerza https:
NS_ERROR_DOM_BAD_URI

Tiene pinta de protección Cross Site Origin, en Gecko, o en el dominio de bootstrap, pero no me acaban de cuadrar las cuentas.
Acabo de probar con Firefox + HTTPS Everywhere y efectivamente es algo con el CORS:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://netdna.bootstrapcdn.com/font-awesome/4.3.0/fonts/fontawesome-webfont.woff2?v=4.3.0. (Reason: CORS header 'Access-Control-Allow-Origin' missing).


Pero no entiendo qué ocurre. Si HTTPS Everywhere cambia la URL del CDN para que se la descargue por HTTPS, debería funcionar igual (si fuese al revés entendería que fallase, pero no es el caso).

¿Alguna idea que no sea alojar los iconos nosotros mismos? Es algo que querría evitar si es posible.

Algunas referencias:
https://meta.discourse.org/t/icons-show ... ites/20282
http://community.freepbx.org/t/firefox- ... sing/27130
http://discuss.emberjs.com/t/this-discu ... ken/6273/2
https://github.com/heiseonline/shariff/issues/76
https://github.com/EFForg/https-everywhere/issues/2425
En este hilo se estuvo hablando bastante pero no se si se llegó a alguna solución:

hilo_iconos-raros-en-eol-al-escribir-mensajes_2154529


Sin probar nada, yo creo que lo que dice kraftner aquí sería la solución: llamar a la fuente directamente sobre https.

Bootstrap debe de estar filtrando en base al protocolo del referrer, porque si no, no tiene sentido. Eso sí, probé cambiando el referrer, pero cuando Gecko cambia el protocolo automáticamente, RefControl no hace nada, así que no he podido saber si influye.

No lo he probado, pero antes de leer eso, lo pensé.

Malo para los que no usen https everywhere, no sería, y malo para los que lo usen, tampoco.

También dice en el link a github de su anterior mensaje que se arregló en Diciembre, cosa que me parece rara con las pruebas hechas aquí :-?

Yo no uso la extensión, lo hago a mano, así que, tampoco. En ese caso sería un bug en Gecko y... ¿tampoco? porque vosotros seguro que estaréis usando ultimísimas versiones de Firefox.

Quién sabe, tal vez Gecko se haga la picha un lío con las interrogantes al forzar https sobre una url dada y se convierta en una url no válida :-?

EDIT: creo que al final es Gecko, porque con el sniffer no llega a salir, o sea, no acepta el cambio de http a https con bootstrap y ni siquiera intenta conectar, pero a saber por qué.
Ghostery tb bloquea la descarga de esas imágenes por defecto. Me equivocaba, cuando me pasó a mi tb era por https everywhere, como dije aquí: viewtopic.php?p=1740856947

La solución es en las reglas de la extensión, eliminar esta regla

<!--
   For other NetDNA coverage, see NetDNA.xml.


   Nonfunctional subdomains:

      - (www.)? *

   * Refused

--><ruleset name="BootstrapCDN.com (partial)">

   <target host="maxcdn.bootstrapcdn.com"/>
   <target host="netdna.bootstrapcdn.com"/>


   <rule from="^http:" to="https:"/>

</ruleset>
Aunque no le veo ni pies ni cabeza, lo he puesto directamente con HTTPS para todo el mundo, a ver si notáis algún cambio.
melado escribió:Aunque no le veo ni pies ni cabeza, lo he puesto directamente con HTTPS para todo el mundo, a ver si notáis algún cambio.


Lo veo todo perfecto sin problema alguno ahora mismo, no sé si esto supondrá un problema para los que no usan HTTPS (soy un ignorante en estas cosas) pero ahora da gusto.

Gracias por tu tiempo [oki]
Puede que sume 40-50 ms en la primera visita a la web, pero no importa demasiado porque los iconos no son necesarios en la primera visita (salvo quizá el del aviso de las cookies pero no es importante), y además ya va siendo hora de que nos pasemos todos a HTTPS, a ver si un día lo hacemos en todo EOL :)
El problema, que, en parte, querías salvar antes (que decías que usando un CDN la fuente ya estaría cacheada en el usuario, para no hospedarla en EOL), es que esos 50ms y xKB de descarga, dependiendo de la fuente que use el navegador, van a ocurrir en todas las sesiones del navegador.

Es lo que tiene el contenido servido a través de https, que salvo que el usuario lo especifique (riesgo de seguridad), no se cachea.

Sería interesante saber si eso va a suponer un gran impacto en los usuarios móviles, pues la media de las fuentes debe andar por los 70KB.

Sobre la segunda parte que dices... uy, después de tanta negativa por las posibles molestias (alertas de seguridad del navegador y otros) al usuario final, y diría sobre proteccionismo al mismo, se agradecería pasarlo todo a conexión segura, o tenerlo como alternativa para los que sabemos lo que hacemos (no pretende ser una crítica destructiva).

No es que lo que leamos aquí sea privadísimo, pero tiene que cundir la idea de que sólo el servidor y el cliente deben conocer qué se ha transferido cuando se navega por la red.


Naifus escribió:Lo veo todo perfecto sin problema alguno ahora mismo, no sé si esto supondrá un problema para los que no usan HTTPS (soy un ignorante en estas cosas) pero ahora da gusto.


Todos usamos https, si el servidor lo implementa.

Cada vez que accedes a tu banco, o a través del navegador a Gmail, Outlook, Yahoo Mail, etc, lo haces sobre https, es decir, una conexión segura.
JohnH escribió:Es lo que tiene el contenido servido a través de https, que salvo que el usuario lo especifique (riesgo de seguridad), no se cachea

Eso pensaba yo y por eso en un principio lo cargaba por HTTP. ¡Pero se ve que estamos anticuados!
http://stackoverflow.com/questions/1743 ... over-https

Sobre la segunda parte que dices... uy, después de tanta negativa por las posibles molestias (alertas de seguridad del navegador y otros) al usuario final, y diría sobre proteccionismo al mismo, se agradecería pasarlo todo a conexión segura, o tenerlo como alternativa para los que sabemos lo que hacemos (no pretende ser una crítica destructiva)

Si se pasa, se pasará todo obligatoriamente. Es un proyecto grande porque EOL está formado por muchas partes, unas más modernas que otras, pero es algo que quiero hacer.
melado escribió:
JohnH escribió:Es lo que tiene el contenido servido a través de https, que salvo que el usuario lo especifique (riesgo de seguridad), no se cachea

Eso pensaba yo y por eso en un principio lo cargaba por HTTP. ¡Pero se ve que estamos anticuados!
http://stackoverflow.com/questions/1743 ... over-https


Pues va a ser que sí. Desde 2011 nada menos.

https://securityevaluators.com/knowledg ... s/caching/


The HTTP header Cache-Control: public.

Firefox contains a hidden browser preference, browser.cache.disk_cache_ssl, that when set to true, switches Firefox from the previous, cautious policy above, to a new policy that strictly follows the HTTP standard, disk caching all content unless specifically instructed not to do so by the server. In 2011, the default value of this preference was switched from false to true [8]. As a result, Firefox 4.0 and all later versions cache HTTPS-delivered content to disk, unless the following is present:

The HTTP header Cache-Control: no-store



Aunque, al fin y al cabo, no deja de ser algo que queda en manos de algunos webmasters/zarpas como muestran en esa misma página.

No sé qué es peor.
Confirmo que he restaurado las reglas y ahora no pasa, tampoco noto retardos ni similar.

Edit: Cojones, hace una semana de que se arregló, así que supongo que mi confirmación sobra XD
Tengo que cambiar de trabajo...
17 respuestas