Mozilla 'herintroduceert' zeven jaar oude bug

Ja ik, ik gebruik ELinks (of gewoon `links`)

Ja probeer dáár maar eens mee te bankieren...

Galeon is heeft er ook geen problemen mee. Voor mij is da nog altijd de beste gnome browser die er is .

Lynx is zooo 2004. In 2005 gebruik je toch links!

Ik wel met openen in nieuwe venster, niet in tabs. Ook met ff 1.0.4

Helaas is Firefox wel gevoelig, als je 'gewoon' op beide links op de test-site klikt, dus niet voor elke link een niewe tab afdwingt of voor elke link een nieuw venster afdwingt dan wordt de test-page in het frame van msdn geladen.

* 786562 Keeper
[edit: net iets te laat sorry]

Als ik beide paginas "gewoon" open (MSN komt in een nieuw venster) dan werkt deze bug nog gewoon onder Firefox 1.0.4., maar sls ik MSN open in een nieuwe tab, dan maakt het niet uit hoe ik de Secunia pagina open (tab of venster) en werkt de bug niet.

*edit* heh, net te laat

Firefox/1.0 (Ubuntu package 1.0.2 MFSA2005-44) is niet kwetsbaar lijkt me (gebruik wel singlewindow extension)

Waarom hebben ze voor dit soort dingen geen geautomatiseerde regressietesten? Zeker als die bug al tig keer is opgedoken lijkt me dat erg handig...

Je kan 'm natuurlijk ook laten submitten náár die popup, heb je de frames ook niet meer nodig.
Frames zijn onnodig, onveilig en lelijk. Ik sluit me volledig aan bij wat Dreams zegt.

Zelf gebruik ik bijvoorbeeld heel vaak een hidden mini-frame waarin ik alle data van een form submit, zodat de hele pagina in beeld blijft. Als er dan gegevens niet volledig zijn ingevuld hoeft de gebruiker niet terug bladeren. Alleen de pop up wegklikken en invullen maar.

Slecht voorbeeld. Je kan beter een 'wijzig' knop maken die de data terugsubmit naar het invul form. Werkt minimaal even goed en, in mijn ogen, zelfs beter. En dat dat zonder frames!

Maar, het voorbeeld van een 'vast' menu gaat wel op en kan heel handig zijn. Aan de andere kant kun je hier voor ook heel goed een iframe gebruiken door de scrollbare data in de iframe zetten. Een iframe is niet gevoelig voor dit soort bugs.

een menu dat altijd zichtbaar blijft is makkelijk te doen met de css tag position:fixed;

[sarcasme]of werkte deze nou niet in IE?[/sarcasme]

Zelf gebruik ik bijvoorbeeld heel vaak een hidden mini-frame waarin ik alle data van een form submit, zodat de hele pagina in beeld blijft. Als er dan gegevens niet volledig zijn ingevuld hoeft de gebruiker niet terug bladeren. Alleen de pop up wegklikken en invullen maar.

Slecht design dus.

Makkelijk op te vangen door aan de serverkant de pagina terug te serveren alsie niet valideert.

Zelf gebruik ik bijvoorbeeld heel vaak een hidden mini-frame waarin ik alle data van een form submit, zodat de hele pagina in beeld blijft. Als er dan gegevens niet volledig zijn ingevuld hoeft de gebruiker niet terug bladeren. Alleen de pop up wegklikken en invullen maar.

[evenmoreflamebait]
Hiermee sloop je dus de navigatie zoals de gebruiker het wel gewend is, die wil bij een fout terug gaan. Tevens is het net zo makkelijk om naar dezelfde pagina te posten en daar je check in te maken, het is maar net hoe moeilijk je wilt doen, persoonlijk vind ik jou manier moeilijk...

Laat me gokken je gebruikt ook vaak frames om te zorgen dat je URL niet vreemd word voor de gebruiker maar gewoon 1 enkele frameset met een enkele frame zodat je altijd www.blaat.org houd?
Bedenk je dan maar alvast wat dat doet voor mensen die een linkje naar iemand anders willen sturen.

Lees het er maar op na: frame zijn zo gebruikersonvriendelijk als het maar kan zijn!


Ter illustratie:
http://www.google.nl/search?q=why%20frames%20are%20bad
[/evenmoreflamebait]

Echt ik wil niet moeilijk doen maar wat je hier zegt is gewoon nonsense. Frames zijn ontzettend handig voor heel veel dingen (zoals een menu dat altijd zichtbaar blijft, etc. etc.) dus om te beweren dat Frames slecht zijn, of, whats more, om te zeggen dat Frames van slecht design getuigen is totale onzin.

Met 'layers' of '<div>'-tags is hetzelfde te bereiken, daarbij komt dat als je hiermee werkt je site nog steeds retesnel is en ipv voor (aantal frames+1) requests aan de server te zenden om te laden wordt dat (ex plaatjes) precies 1. Menu kan je ook netjes op de plaats houden, en je hebt het voordeel dat je alles mooi overzichtelijk in 1 bestand hebt staan.

Zelf gebruik ik bijvoorbeeld heel vaak een hidden mini-frame waarin ik alle data van een form submit, zodat de hele pagina in beeld blijft. Als er dan gegevens niet volledig zijn ingevuld hoeft de gebruiker niet terug bladeren. Alleen de pop up wegklikken en invullen maar.

+

De pop up being a Javascrip alert. Server side controleren, daarna client side een Javascript alert tonen. Werkt uitstekend.

Waarom laat je het niet clientside mbv javascript controleren? Een 'hidden frame' puur om alleen maar wat zooi in te gooien is in mijn ogen prutswerk. Forms controleren mbv javascipt moest ik pas nog voor een vak op school. Scheelt ook weer in werk voor de server.

Een menu dat zichtbaar blijft (bij een scrollende website) is in mijn optiek alleen maar irritant en niet meer van deze tijd.

Als je bijv. op een website naar beneden scrollt, dan onthoud je onderbewust waar het menu zich bevind. Je verwacht dat dat wegscrollt samen met de rest van de content. Dit gebeurd ook als je een krant of een boek leest, toch?

Inscribed by Webdoc:
Echt ik wil niet moeilijk doen maar wat je hier zegt is gewoon nonsense. Frames zijn ontzettend handig voor heel veel dingen (zoals een menu dat altijd zichtbaar blijft, etc. etc.) dus om te beweren dat Frames slecht zijn, of, whats more, om te zeggen dat Frames van slecht design getuigen is totale onzin.

Frames = Bah, punt.
Probeer eens wat anders zoals bijvoorbeeld PHP's "require()" en wat losse bestanden (bijvoorbeeld het menu), je zou zelfs het menu dynamisch kunnen maken, de links in het menu ook, whatever, het kan met wat creativiteit. Ikzelf gebruik nooit frames Ik ontwikkel nu een fixed menu dat meereist met elke pagina die ik op een site hang, simpelweg door het op te roepen met require(), hetzelfde doe ik met de headers van elke pagina. Pagina zelf kan weer ingedeeld worden met bijv. tabellen die meerekken met de grootte van het browservenster, etc.
Het is maar wat je ervan maken wilt.

Helemaal eens! D'r houdt verdorie nooit iemand rekening met Lynx gebruikers, en frames zijn echt k*t in lynx! (Gelukkig heb ik nu links).

Ik heb geprobeerd mijn site [codingdomain.com] in links weer te laten geven. Het gaat tot zo heel aardig dankzij het gebruik van XHTML. Maar het onderstaande geeft toch een idee waarom er bijvoorbeeld geen rekening gehouden wordt met Links:

Links liep in mijn site vast op de <dd><pre>...</pre></dd> opmaak. De hele marge wordt daarmee verpest. Mijn site heeft een heldere interne structuur en zaken als <dt>..</dt> (een definition-title) hadden eenvoudig door Links gehighlight kunnen worden. Nu heb ik er speciaal voor links een extra <em> ingezet om het een beetje overzichtelijk te houden. Tabellen op mijn vim-reference pagina werken ook totaal niet goed weergegeven, dat wordt een lange stroom van letters.

Toen heb ik het dus opgegeven. Links is leuk maar dus niet zaligmakend. Voortaan vind ik het leuk meegenomen als Links nog wat van normale XHTML code kan maken, maar besteed er niet teveel aandacht aan.

Eh... en wat is het voordeel van lynx verder voor normale surfers? Ik was eigenlijk onder de indruk dat alleen blinden lynx gebruikten i.c.m een brailleprinter.

Maar ik kan me vergissen, dus als iemand het me kan vertellen?

Klopt. De Secunia-advisory is hier te vinden.

Edit: dit heb ik overigens uit deze Slashdot-thread over hetzelfde onderwerp.

Maar het is niet zo slim om deze functie per default toe te laten.

Het probleem met beveiligingsinstellingen is dat ze vrijwel altijd functionaliteit beperken. Kijk maar eens naar je firewall: Heb je die wel eens uit moeten zetten omdat een programma anders niet werkte? Vast wel...

Dus het is altijd een spanningsveld: wat zet je aan en wat niet? Toch horen dit soort lekken niet voor te komen en is er op dit moment voldoende 'veilige' technologie zonder dat het direct de functionaliteit inperkt.

Was het ESR die dit zei? Given enough eyeballs, all bugs are shallow.
Of deze bug is een contradictie hiervan, of er werken niet genoeg mensen aan Mozilla ...

Sorry, maar dan ben je gewoon een beetje kortzichtig en absoluut niet op de hoogte. Firefox start de eerste keer iets trager op, de rest van je Windows sessie is dit niet het geval, en hoevaak reboot jij XP/2K nog ?