Firefox quer minimizar travamentos de Flash
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)
• Publicado por Augusto Campos em
2010-03-10
@brlinuxblog
Feed RSS
Já passou da hora de acabar com o Flash
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.
@Júlio
Hever Costa Rocha diz:
“O Flash está morto”
O Flash diz:
“O Hever está morto”
HTML5 com JavaScritp diz!
“Vida nova para WEB”
http://mrdoob.com/lab/javascript/harmony/#ribbon
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
Demorou! É desagradável você estar pesquisando e derrepente “TRAVOU”, ai você não sabe se foi o navegador ou o recurso do site, e geralmente concluí-se que é o FLASH, por isso que desenvolvo sites só em DHTML(XHTML+CSS+AJAX)
To vendo que o HTML5 vai ganhar em cima disso…
Em cima de um PLUGIN BUGADO…
Nego vai preferir ter “menos recursos” que ficar com os recursos dele travando..
Como desenvolvedor web, nunca vi nada de útil no flash.Nunca tive um cliente reclamando de JQuery/xhtml. Morte ao flash.
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…
:)
@Dyego Souza do Carmo
A Onda Anti-Flash sempre existiu :-D desde o surgimento dessa abominação (Web), até os dias de hoje. E as fileiras de insatisfeitos só tem aumentado. Espero que o Flash seja extinto em um curto espaço de tempo. Não dá para conviver com algo que aprapalha tudo (de navegador a SEO), além de precisar de um plugin fechado, ultra-pesado, cheio de bugs, etc.
E viva os padrões abertos e a tecnologia livre o/ o/ o/
Um lixo ainda pior que a Adobe faz para o linux é o acrobat reader e seu plugin pdf para o firefox. É pesadão e o plugin várias vezes falha na abertura de PDFs dentro do navegador.
@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.
Em tempo, gastar mais memória por separar as abas em processos não é realmente um fator determinante. Isso vai do navegador em si.
O problema é que o pessoal compara o Chrome, um dos piores avaliados, com o Firefox, o melhor avaliado nos testes em geral. Uma comparação entre Opera vs. Chrome revela que o problema é mais embaixo… ;)
[]‘s
Quem quiser mais informações sobre processos e navegadores leia este artigo do IEBlog: http://blogs.msdn.com/ie/archive/2010/03/04/tab-isolation.aspx
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..
@alberto
MSDN mano?
Não tinha nada mais “imparcial” não?
@Allan
Ai não dá pra tratar com 2 pesos 2 medidas. Eu prefiro que consuma MAIS memória, e tenha uma isolamento que não precise reiniciar o Browser qdo um plugin dá crash, do que ter um Firefox em 32Mb de Ram, que qualquer site com flash, lasca todas minhas abas…
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 ;)