Firefox quer minimizar travamentos de Flash
Leia também:
- Oracle silenciosamente desativa servidores de teste do PostgreSQL para Solaris
- Mais de um milhão de usuários do Android foram expostos devido a app malicioso
- Abrindo aplicativos web como se fossem desktop com o Google Chrome
- Configurando um webmail como aplicativo padrão no Ubuntu
- Motorola promete tablet com Android 3.0
- Be-a-bá do SSH, parte 1
Por aí trava? Do iG Tecnologia:
O Flash é uma das causas mais comuns de travamento de navegadores web. Sabendo disso, a Fundação Mozilla prepara uma melhoria no Firefox que ajudará o navegador a lidar melhor com esses travamentos.
Os desenvolvedores do navegador estão testando um recurso que isola o Flash em um processo separado. Assim, mesmo se o plug-in travar, as outras abas e sites abertos no navegador continuarão funcionando normalmente.
Esse método já é usado em outros navegadores, como o Chrome, do Google. (via tecnologia.ig.com.br)
Como solução “rápida” de incidentes, eles poderiam fazer o mesmo esquema do chrome, que trata cada aba como processo diferente.
Basta matar a aba que o flash tá travado, e pronto, não dá pau no browser inteiro =)
E depois sim, fazer com que o plugin do flash cause menos travamentos.
Na minha opinião, o Firefox deve continuar a gerenciar todas as abas em um único processo, assim gasta menos memória. Se já o chamam de comilão de memória agora, imagine depois de separarem os processos por abas! Sem contar que isso não deixa o navegador mais estável, só vai evitar de fechar outras abas. É eficiente, mas não eficaz. Entretanto, achei boa a ideia de isolar o processo dos plugins em processos separados (principalmente o do Flash), já que estes é que tornam o navegador instável.
O flash é instável principalmente no Firefox e no Opera. O Chrome parece se dar melhor.
Mas em todos os navegadores no Linux, o Flash fica muito mais pesado do que na versão correspondente para Windows. No Windows o Flash fica bem mais leve.
“Sem contar que isso não deixa o navegador mais estável, só vai evitar de fechar outras abas.”
Não consegui entender seu raciocínio.
Ou a Adobe arruma esse plugin , ou terá serios problemas se uma onda “anti-flash” se instalar…
Por enquanto é um ou outro falando… daqui a pouco vai virar um turbilhão , clientes vão começar a boicotar o flash…
O Flex morre , o AIR morre (se já nao tá morto)…
A Adobe precisa parar com essa manina de fazer TUDO PARA TODOS , mas TUDO meia boca.
Eu acho que deve continuar
Lembrando que a tática de isolar o plugin num processo externo já era usado há tempos no Opera e Konqueror, por pura questão de compatibilidade, já que o plug-in flash usa Gtk enquanto estes navegadores usam Qt. Para isso usam uma camada de compatibilidade com plugins do netscape (o mesmo pra familia mozilla).
Comigo não trava quando estou usando o Firefox, só trava no Konqueror.
@Allan
“Na minha opinião, o Firefox deve continuar a gerenciar todas as abas em um único processo, assim gasta menos memória…”
como você chegou a essa conclusão?
Cheguei a essa conclusão ao ver o quanto o IE 8 e o Chrome gastam muita memória com várias abas abertas, mais do que o Firefox com o mesmo número de abas.
Seria interessante se o Firefox e/ou o Chrome possibilitassem ao usuário se ele deseja usar um único processo para todas as abas ou usar um processo por aba.
Uma sugestão seria utilizar o melhor dos dois mundos…
Caso a pagina acesse ALGUM PLUGIN ela automaticamente é isolada em um processo separado…
Caso não.. ela abre dentro do mesmo executavel…
:)
@Allan
“Na minha opinião, o Firefox deve continuar a gerenciar todas as abas em um único processo, assim gasta menos memória…”
como você chegou a essa conclusão?[2]
“Cheguei a essa conclusão ao ver o quanto o IE 8 e o Chrome gastam muita memória com várias abas abertas, mais do que o Firefox com o mesmo número de abas.”
E desde quando IE8 e “olhometro” são padrões de comparação confiáveis?
@Ironmaniaco
A Mozilla adotou a tua idéia ao contrário. Vou reproduzir aqui o que eu postei no MeioBit dias atrás:
Vale lembrar que, apesar da Mozilla estar mais “lenta”, ela tem melhorado gradativamente atacando os pontos que ela entende serem primordiais [...] (este trecho é uma conclusão pessoal fundamentada no uso das informações do Mozilla Crash Reports pela própria Mozilla)
No Firefox 3.6, foi introduzido o Component Directory Lockdown, que fecha as portas para um antigo método de “expandir” o navegador por extensões e plugins, método este responsável por uma quantidade de crashes e leaks considerável nos dias atuais e que, portanto, mereceu a correção.
Também no Firefox 3.6, foi introduzido o novo PluginCheck, um atualizador de plugins (Flash, Java, etc.). Apesar de mirar principalmente na segurança dos usuários, é algo que, fazendo eles atualizarem os plugins, acaba reduzindo os crashes e leaks, visto que o Flash principalmente é conhecido por ser o maior vilão, como você bem disse.
Pro Firefox 3.7 o desenvolvimento já nos revela uma medida mais empolgante: Out-Of-Process Plugins. Finalmente os maiores vilões estarão isolados e, ao travarem, bastará recarregarmos suas respectivas abas.
A novidade vem já na próxima versão do Firefox, que não necessariamente precisa ser a 3.7, talvez pulem pra 3.8 ou 3.9 se assim desejarem. Os travamentos de plugins nesta nova versão serão reportados automaticamente à Mozilla, sem a intervenção do usuário. O procedimento para travamentos do Firefox em si continua como antes.
[]’s
Quanto ao Firefox ter as abas distribuídas em processos, Allan, quanto a isso você não precisa se preocupar: se isto for tirar do Firefox o posto de navegador com melhor gerenciamento de memória (posição sustentada há quase 2 anos, desde o Firefox 3.0)*, a Mozilla certamente não mudará. Sei que eles estão rumando para isto, mas eles devem estar tendo resultados positivos para que esta mudança aconteça efetivamente. ;)
* http://lifehacker.com/5457242/browser-speed-tests-firefox-36-chrome-4-opera-105-and-extensions, http://www.tomshardware.com/reviews/firefox-chrome-opera,2558.html, http://arstechnica.com/open-source/news/2008/03/firefox-3-goes-on-a-diet-eats-less-memory-than-ie-and-opera.ars
@Paulo Freitas
Opa…esse treco de Out-Of-Process Plugins parece bem interessante =)
E desde quando IE8 e “olhometro” são padrões de comparação confiáveis?
O IE 8 pode não ser, mas o Firefox e o Chrome são. E não se trata de olhômetro apenas, verifiquei o consumo pelos verificadores de consumo de memória do Windows e do (GNU/) Linux (neste sistema, só comparei o Chrome e o Firefox).
E cada aba do IE 8 e do Chrome consomem, pelo que vi, a mesma quantidade de memória do que o navegador todo, ao invés de aumentar apenas um pouco de memória, como ocorre no caso do Firefox e no do IE 7.
Resolvi fazer um teste aqui:
Desabilitei o falsh e vou deixar assim pelo menos por essa semana (ou até eu realmente precisar dele, o que demorar mais), vamos ver se sinto falta.
Pelo que eu observei esse plug-in só esta aqui para mostrar propaganda então pode perfeitamente sair. Nenhum dos sites que eu acesso tem aqueles famigerados menus em flash.
Quando o Flash trava no Chrome ele nem fecha a aba que travou, e sim mata o plugin do flash em todas as abas..
Eu não tenho certeza, mas pela minha esperiência, nem precisa reiniciar o navegador pra plugin voltar a funcionar..
http://blog.chromium.org/2008/09/google-chrome-memory-usage-good-and-bad.html
Multi-process Model Disadvantages
While the multi-process model provides clear robustness and performance benefits, it can also be a setback in terms of using the absolute smallest amount of memory. Since each tab is its own “sandboxed” process, tabs cannot share information easily. Any data structures needed for general rendering of web pages must be replicated to each tab. We’ve done our best to minimize this, but we have a lot more work to do.
(continuando o texto do blog do chromium)
Example: Try opening the browser with 10 different sites in 10 tabs. You will probably notice that Google Chrome uses significantly more memory than single-process browsers do for this case.
Não se trata de dois pesos e duas medidas. Não sei onde viu isso.
Pois eu prefiro que o navegador consuma menos memória e ao mesmo tempo não trave com nenhuma das abas do que ele gastar mais memória e travar uma aba.
No momento, o Firefox tytrava todas as abas caso o Flash dê pau, entretanto, com o isolamento do Flash (e qualquer outro plugin) em um processo separado, aí nenhuma aba travará, a não ser por problemas do próprio Firefox, mas daí isso só ocorre com versões de desenvolvimento e a responsabilidade é dos desenvolvedores deste para sanar os travamentos, e não dos desenvolvedores de um plugin que não estão nem aí para o navegador.
@Allan
então a conclusão é que o firefox isole apenas processos de abas com plugins. ;)
O que é o conceito do Out-Of-Process Plugins que o Paulo citou acima. Simples.
A Adobe deveria abrir o código do Flash Player e torná-lo Open Source. Desse jeito eles vão perder a batalha!
MSDN mano?
Não tinha nada mais “imparcial” não?
Infelizmente não. Quem mais conhece profundamente como funciona isso que não seja MS, Mozilla, Google ou Apple?
Allan Taborda dos Santos (usuário não registrado) em 10/03/2010 às 2:28 pm:
“E cada aba do IE 8 e do Chrome consomem, pelo que vi, a mesma quantidade de memória do que o navegador todo, ao invés de aumentar apenas um pouco de memória, como ocorre no caso do Firefox e no do IE 7.”
é o esperado — pelo menos no caso do Chrome, que usa um processo em separado para cada aba, ao invés de threads dentro de um mesmo processo. A justificativa do Google é que, além da segurança e estabilidade adicionais de um processo por aba, é que normalmente uma página hoje em dia gasta mais memória do que o processo responsável por ela. Se isso se verifica na prática, aí é outra coisa…
Justamente por o Flash ser instável, principalmente no Mac OS X, instalei a extensão flashblock no Firefox e clicktoflash no Safari. A ventoinha do processador agradeceu ;)
A Mozilla ultimamente está com um “timming” triste de ver, chega atraso em quase tudo.
A muito tempo o Flash faz o Firefox travar, eles tem estatistica disso, mas só agora resolveram fazer alguma coisa. Possivelmente porque o Chrome já faz isso.
Além disso, a ultima versão (64bits) do Flash é muito estável, não me lembro se essa versão de flash já travou alguma vez. E justo agora a Mozilla resolve isolar o flash.
Que continue assim os problemas do flash assim poderei vender mais minhas soluções RIA em javascript, a próprosito só dou suporte apenas o google chromer para minhas aplicações RIA WEB.
Since each tab is its own “sandboxed” process, tabs cannot share information easily. Any data structures needed for general rendering of web pages must be replicated to each tab. We’ve done our best to minimize this, but we have a lot more work to do.
E bota lot nisso… Dá pra melhorar muito.
O Firefox.next está mirando neste conceito de multi-processo e eu estou confiante de que a Mozilla dará seus pulos para que isto não estrague o consumo de memória. Até lá o Mozilla Toolkit vai ter amadurecido bastante com os refatoramentos, dá para esperar por algo muito melhor do que o Chrome nos dias de hoje. :)
[]’s
Melhor usar o pluguin ”NoScript” que só carrega flash e outros serviços caso você queira e evita de cair em páginas com vários arquivos flash carregando ao mesmo tempo que se torna um convite a lentidão e travamentos eu uso o Seamonkey.
@Allan
analizar o consumo de memória de programas rodando com multiplos processos não é trivial.
você sabe que existem várias formas de medir, igualmente válidas, mas que podem dar resultados diferentes, correto?
um exemplo é que somar a memoria consumida por todos os processos não é o mesmo que medir a memória do programa como um todo, no caso de haver memória compartilhada.
isso é fácil de entender usando a teoria dos conjuntos. o numero de elementos da união entre os conjuntos A e B é o número de elementos de A, mais o de B, menos o da interseção entre A e B.
isso em si é algo curioso: os processos podem compartilhar quanta memória for conveniente!
analizar a partir do ‘consumo total de memória’ antes do programa iniciar e depois também pode ter suas falhas: a memória utilizada pelo sistema operacional como ‘cache’ pode entrar na conta, e atrapalhar tudo.
além disso, um browser que gasta muita memória com poucas abas abertas pode gastar pouca com muitas abas, em comparação com outros browsers que possuem um comportamento inverso.
–
além disso, não dá pra comparar diretamente os méritos de separar entre processos ou não usando programas completamente diferentes. as escolhas que cada um dos browsers fez foram diferentes. usar vários processos é só uma dessas escolhas, que pode ou não ter impacto no consumo de memória.
por exemplo, é possível que o interpretador javascript do google consuma mais memória, e em troca execute javascript mais rapidamente. se esse for o caso, talvez você esteja culpando o vilão errado.
O firefox suporta html5, o problema em abrir videos do youtube esta em relacao ao codec usado. Codec esse que a mozilla nao pretende utilizar tao cedo, em favor de uma internet livre.
“We want to make sure that the Web experience is good for all users, present and future,” Shaver writes, “I want to make sure that when a child in India or Brazil or Kenya discovers the internet, there isn’t a big piece of it (video) that they can’t afford to participate in. I want to make sure that there are no toll-booth barriers to entry for someone building a whole new browser, or bringing a browser to a whole new device or OS, or making and using tools for creating standard web content.”
http://www.osnews.com/story/22787/Mozilla_Explains_Why_it_Doesn_t_License_h264
http://www.osnews.com/story/22771/YouTube_Launches_HTML5_Beta_Forgets_the_Open_Part
@Allan
Não é bem assim que as coisas funcionam. O isolamento das abas em processos distintos consome muito mais memória, mas traz vantagens. No Firefox, se um javascript consumir muitos recursos em uma página, o browser inteiro congela. No Chrome, isso não acontece. O Firefox pode consumir menos memória, mas não é mais leve. Tenho um Turion X2 2.0Ghz e o Firefox congela com frequência, enquanto o Chrome roda perfeitamente. Além disso, eu prefiro que as abas não compartilhem conteúdo, por questão de segurança. É possível criar ataques incluindo scripts em sites para roubar conteúdo de outras abas (imagine você com o Gmail aberto e navegando em outra aba).
Eu costumo sempre instalar um plugin aqui, flashblock, ele é simples e eficaz, só rodo o plugin do flash quando quero ou para sites que quero.
Percebi que o problema do FF era o Flash por sempre utilizo esta extensão. Existem outras similares (não tenha similar no sentido pejorativo e sim o da palavra, sabemos que existes outros bons plugins para impedir a execução do flash)
Eu gostaria de saber por que o meu comentário foi bloqueado, se o MarcusJabber respondeu bem a minha questão? Eu também concordo que o uso de flash faz o firefox ficar bem lento. Se há uma tecnologia que pode minimizar isso, porque sou bloqueado por questionar o seu uso?
Eu trabalho com desenvolvimento em flash também, mas eu não estou cego e não vendo que o meu firefox consome muitos recursos da máquina quando usa essa mídia.
Enquanto não fica pronto, FlashBlock é uma boa opção =D