Noch kein Kommentar? Kaum jemand nutzt also noch FF und wenn, dann max. v11.

10.5? Ist das sicher? Ich dachte, der FF läuft seit der 17 nur noch ab 10.6?

Dr. Frank N. Stein
Ich habe den Text korrigiert. Es wird mindestens 10.6 benötigt.

Wo muss ich da einen Zusammenhang erkennen?

Was für softwaretechnische Klimmzüge müssen die Entwickler von Firefox da machen?!?

Bei Mac-Programmen, wie der Safari z.B., wird diese Funktion vom Betriebsystem vererbt. Der Programmierer muss das nicht selbst schreiben. Deswegen kann Safari PDFs anzeigen, auch ohne das Adobe-Plugin, welches von Adobe aber immer wieder ungefragt installiert wird.

Großes Interesse am Thema, am Produkt etc. viele Kommentare in kürzester Zeit,
geringes Interesse am Thema, am Produkt etc. nach Stunden noch kein Kommentar

Oh je, der Gerhard wieder.

Safari OSX only
Firefox OSX, Windows, Linux, *BSD, ...

Ich könnte mir vorstellen, daß das einer der Faktoren ist.

Gerhard Uhlhorn:

Bei Mozilla hat man sich GANZ BEWUSST GEGEN eine solche native Lösung entschieden. Man hat das durchaus in Erwägung gezogen und lange durchdiskutiert. Es sind allein Sicherheitsgründe, weshalb man das auf diese Weise macht. Weil jegliche PDF-Lösungen, die auf einem Plugin oder ein natives Framework des Betriebssystems setzen, anfällig sind für sicherheitstechnische Lücken, die ausgenutzt werden können. Auch MacOSX'ens eigenes PDF-Framework ist anfällig dafür, wie mehrere schon aufgetauchte Lücken und Fixes und Exploits, die diese Lücken in iOS und OSX ausgenutzt haben, schon bewiesen haben und den Mozilla-Entwicklern damit gezeigt haben, dass ihr Denkansatz mit pdf.js der Richtige ist und sie gut daran getan haben, auf den für sie komplizierteren aber sichereren Weg zu setzen anstatt den bequemen Weg zu gehen und per Vererbung MacOSX' eigenes PDF Framework zu nutzen (für 32bit Firefoxen (FF 3.x) gibt es seit langem ein Add-On, das genau das tut und das native OSX Framework nutzt, jedoch ist dieses Add-On nicht 64bit-fähig, und die Entwicklung davon wurde vom Entwickler inzwischen eingestellt: firefox-mac-pdf, PDF plugin for Firefox on Mac OS X ).

pdf.js wird mit HTML5, JavaScript und SVG umgesetzt uns ist deshalb prinzipiell sicherer als solche nativen Lösungen und kann im Zweifel auch leichter gefixt und deaktiviert werden, sollte damit mal was im Argen sein, so jedenfalls die Meinung der Mozilla-Leute. Weil alles intern im Browser abläuft und den Webstandards-spezifischen Sicherheits- und Sandbox-Regeln unterworfen ist.

pdf.js ist übrigens als browserneutrale Lösung konzipiert und kann von jedem anderen Software-/Browser-Hersteller ebenfalls benutzt und eingesetzt werden, der Interesse dran hat, das ist bewust von den Mozilla-Leuten so vorgesehen und auf der Projektseite auch so gesagt. Eine Browser-Erweiterung für Google Chrome z.B. ist von vornherein ebenfalls von den Mozilla-Leuten vorgesehen und wird von ihnen regelmäßig gebaut bzw. lässt sich selber bauen.

Es ist also kein Bug oder Unvermögen, dass pdf.js so ist wie es ist und dass es Mehrarbeit für die Mozilla-Entwickler bedeutet, sondern das ist ein von den Mozilla-Entwicklern gewolltes Feature, und sie nehmen die dazu nötige Mehrarbeit gerne in Kauf zugunsten einer erhöhten Sicherheit und einer kleineren Angriffsfläche für PDF-basierte Angriffe von außen.

teorema67:
Wunschdenken? Safari hat unter 10% Marktanteil in Deutschland, Firefox über 45%.

Und warum nervt dich das, wenn andere Surfer andere Browser bevorzugen als du?

Ach, tatsächlich? Sag an.

Natürlich liegt es daran, das schrieb ich ja auch. Denn Bei Mac-Programmen erben diese die PDF-Funktionalität vom Betriebsystem. Und das zeigt eben, wie wichtig es ist ein leistungsfähiges Betriebsystem zu haben.

Systemübergreifende Programme können die leistungsfähigen Funktionen des Systems gar nicht nutzen, denn es gibt sie nicht bei anderen Systemen. Deswegen verwende ich auch kein Firefox und kein Chrome, denn die nutzen alle diese tollen Sachen nicht.

sierkb: Ja, es könnte sein, dass Du Recht hast. Allerdings geht es – glaube ich – eher darum, dass diese vom System vererbte PDF-Fuktionalität unter anderen Systemen nicht zur Verfügung steht. Es wäre dann ein Mac-only Feature.

Hätte Windows auch so eine Funktionalität, welche es an Programme vererben kann, könnte man so was einbauen. Da man es aber für Windows ohnehin selbst programmieren muss, kann man das selbst Programmierte dann auch gleich beim Mac verwenden.

Darunter leiden leider auch alle systemübergreifenden Rechnungs-Programme. Die haben entweder gar keine, oder eben eine minderwertige PDF-Funktionalität. Lediglich Mac-only-Programme haben eine wirklich gute Einbindung von PDF.

Wo?Du bist ein schönes Beispiel dafür, warum man nicht mit Fundamentalisten und Quasireligiösen diskutiert. Es macht aber spass Diskussionen mit Leuten wir dir zu verfolgen, so wie bei dieser Energiesache (Schwachsinnige... euer Bus fährt).

Gerhard Uhlhorn:

Nicht zwangsläufig und automatisch. Nur dann, wenn die betreffenden Entwickler das wollen und von diesen Möglichkeiten Gebrauch machen wollen. Und die Mozilla-Leute WOLLEN es ganz bewusst NICHT in diesem Fall, sie haben lange Vor- und Nachteile bzgl. PDF abgewogen. Und sich dann für diese Lösung entschieden.

Das auch seine Schwächen hat und haben kann. Und man nicht zuletzt auch aus sicherheitstechnischen Gründen nicht unbedingt gewillt sein muss, diese Schwächen sich freiwillig ins Haus zu holen, wenn man sie umgehen kann.

Du redest totalen Müll. Wenn Du wüsstest, wieviel natives Zeugs Firefox und Chrome mittlerweile verwenden und bzgl. OSX und iOS auf native Frameworks und Vererbung setzen. Warum wohl setzt Mozilla bzgl. OSX da mittlerweile die Schere an und lässt die Leopard-Generation über die Klippe springen und unterstützt sie nicht mehr? Weil die für Firefox wichtige moderne native OSX-Frameworks nicht hat und ohne die bestimmte Funktionalitäten von Firefox unter MacOSX nicht erreichbar wären und sind! Firefox macht inzwischen ganz erheblichen Gebrauch von so einigen nativen OSX-Frameworks von zentraler Bedeutung und bindet sie via Cocoa ein! Und bei Google Chrome wird es nicht anders sein. So erheblich, dass eben ein Leopard-Betriebssystem nicht mehr ausreicht, um einen modernen Firefox laufen zu lassen, weil Leopard die dazu nötigen modernen Frameworks (die Apple seit einiger Zeit z.B. auch vermehrt ausschließlich nur noch als Cocoa und nicht mehr Carbon zur Verfügung stellt und bald wohl auch nur noch ausschließlich in 64bit) fehlen.

Firefox ist nativer und nutzt auf dem Mac mehr nativ vom Betriebssystem zur Verfügung gestellte Frameworks und Widgets und ist Cocoa-lastiger als so mancher glaubt. Da hat sich in den letzten Jahren so Einiges getan. So Einiges!

aa:

+1

Ach ja: trotzdem ist Safari nur ein mittelmäßiger Browser. Ist schin erstaunlich, wie der such durchsetzen konnte, obwohl der am Anfang so richtig schlecht war und es min. mit Camino bessere gab.

Tja, wer lesen kann, ist klar im Vorteil.

sierkb: Das stimmt ja auch fast alles was Du sagst, aber:

Grundsätzlich gilt:
Wenn man eine Funktionalität von System A verwenden will, dann hat man diese nur auf System A zur Verfügung, nicht aber auf anderen Systemen.

Gäbe es jetzt unter System B und System C auch so eine vom System vererbte Funktionalität, könnte man verschiedene Versionen des Programms machen, die alle die jeweilige Funktion der Systeme nutzen.

Wenn aber eines der Systeme so eine Funktionalität nicht bietet, gibt es nur drei Möglichkeiten:

• Man verzichtet ganz auf diese Funktion
• Man bietet diese Funktion nur für die entsprechenden Systeme an
• Man schreibt sie selbst und kann sie so systemübergreifend anbieten

Und Firefox muss sich eben für eine der 3 Varianten entscheiden.

Die Vor- und Nachteile von einer vererbten Funktion haben damit erst mal nichts zu tun. Das ist nämlich ein ganz anderes Thema. Und da stimme ich Dir auch zu, dass es problematisch sein kann.

Er war anfangs schlank und schnell und nicht so überladen wie die Browser seinerzeit. Und er nutzte und nutzt noch heute die vom System vererbten Eigenschaften wie PDF- und PostScript-Funktionalitäten, systemweite Rechtschreibung, systemweite Textersetzungen, systemweites Colormanagement, systemweite Shortcuts wie z.B. alt-Cursor um wortweise zu springen, systemweite Spotlight-Suche im Browser-Verlauf usw. usw. usw.

Gerhard Uhlhorn:

Aber nicht grundsätzlich nach dem XOR-Prinzip Ent- oder weder.
Sondern von Fall zu Fall individuell und je nach Anforderung und Entscheidung der Entwickler.
Manchmal ist es eben im Sinne einer oder mehrerer Kriterien sinnvoll, etwas anders zu machen als der einfach, naheliegende Weg bzw. auf native Vorgaben zugunsten einer einer eigenen davon abweichenden Lösung zu verzichten. Selbst der Internet Explorer nutzt z.B. keine nativen Widgets in Formular-Elementen, obwohl das per Vererbung seitens des Betriebssystems möglich wäre, sondern zeichnet sie völlig neu (imitiert sie also). Warum? Weil das Mitschleppen/Erben des zugrundeliegenden Windows-Frameworks gerade in Zeiten von Prozess-basierten Browsern im Gegensatz zu Thread-basierten Browsern (Stichwort: pro Tab ein neuer Prozess) ganz schnell enorm viel RAM-Speicher verschlingen würde, weil jedesmal aufs Neue nämlich auch das betreffend geerbte Framework im Speicher kopiert würde und damit schnell viel Speicher verbraten würde. Und auch Apple macht's bei Safari genauso. Aus gleichen Gründen. Auch Safari pinselt aus dieser Kosten-/Nutzen-Abwägung einige Elemente nach, imitiert sie also lieber aus Ressourcengründen, anstatt per Vererbung einfach was Bestehendes zu nehmen. Weil stupide Vererbung eben NICHT immer der besserere Weg unterm Strich ist und manchmal eben auch Nachteile mit sich bringt, die man nicht immer gewillt ist zu schlucken.
Firefox hält man das immer generell vor, doch es kann sehr gute und gut durchdachte Gründe geben, warum man das so macht und nicht anders, obwohl man technisch und vom Wissen her durchaus in der Lage wäre, systemeigene Frameworks an der Stelle zu nutzen und man sich damit auch evtl. viel Arbeit ersparen könnte. Manchmal ist aber zusätzliche Arbeit und ein kleiner Umweg die bessere Wahl, um zum Ziel zu kommen bzw. um bestimmte Nachteile zu umschiffen.

Doch. Und wie das damit zu tun hat in diesem Fall! Beschäftige Dich einfach mal mit der MAterie und lies genau nach die ganzen Blog-Postings, Wiki-Einträge, Bug-Diskussionen und Diskussionen auf Mozillas Mailinglisten zu diesem Thema. Die haben sich schon was dabei gedacht, dass sie es genau so machen und nicht anders und haben Für und Wider einer nativen Lösung und das Zurückgreifen auf das von OSX bereitgestellte PDFKit Framework sehr wohl abgewogen und anderen Lösungen gegenübergestellt. Es ist nach diesem Diskussions- und Abwägungsprozess eine ganz bewusste Entscheidung der Entwickler gewesen, NICHT auf PDFKit zu setzen und diese, auf Webstandards basierende Lösung zu favorisieren. Ganz bewusst ist das gemacht worden. Aus verschiedenen Gründen. Unter anderem eben auch aus Sicherheitsgründen. Und jeder Fix von Apple an PDFKit aufgrund ausgenutzter Sicherheitslücken im PDF-Framework von OSX und iOS gab ihnen im Nachhinein Recht, die richtige Entscheidung getroffen zu haben. Auch das kann man alles nachlesen.

Das habe ich auch nicht behauptet.

1. pdf.js existiert und ist eine JS-basierendes Framework zur Anzeige von PDF Dateien. Deine „Vorschau.app“ basiert ja auch auf irgendwas, das jemand programmieren muss. Nur eben in Objective-C statt JavaScript.

2. Das PDF-Plugin von Adobe wird unter Firefox nicht ungefragt aktiv, weil eigentlich alle Browser inzwischen das externe unterschieben von Plugins und AddOns unterbinden. Gerade gestern bei der Installation der CS6 gehabt: Beim Start von Firefox fragt er, ob man sich das Ding wirklich unterschieben lasse wolle oder nicht.

3. Die Idee hinter der Anzeige von PDFen im Browser ist, dass in Zukunft das „Betriebssystem unter dem Browser“ nicht mehr existiert. FirefoxOS, ChomeOS. In Zukunft wird „da drunter“ kein Mac OS, Windows oder whatever existieren, an das man die schwierigen Sachen delegiert. Google mal nach Chromebooks, die gibt es jetzt schon.

Gerhard Uhlhorn:

Ich nehme an, Du beziehst Dich auf Camino. Und in dem Zusammenhang liegt die betonung wohl auf dem Wörtchen "war anfangs". Mittlerweile ist Camino im Grunde tot, seitdem die Core-Entwickler das Projekt verlassen haben (in Richtung Google, um an Chrome zu arbeiten und in Richtung Apple, um an Safari zu arbeiten), hat eigentlich kaum mehr Entwickler und Interessenten und hinkt technologisch dem Firefox um Jahre hinterher. Das, was Camino einst ausmachte, nämlich die native Nutzung von OSX Frameworks und Elementen und Features und die nahtlose Integration in OSX hat Firefox mittlerweile auch, und der Cocoa-Code vom heutigen Firefox dürfte um Einiges aktueller und moderner sein und aktuelle Apple-Vorgaben und moderne Errungenschaften des Betriebssystem diesbzgl. besser erfüllen als der alte Code des Camino. Camino ist bestenfalls, die Nightlies inbegriffen, auf dem Stand von Firefox 3.6. Auf Gecko 4 bzw. Firefox 4 konnte/kann Camino den Sprung nicht machen, weil die Mozilla-Leute die APIs teilweise radikal geändert haben und es eine für Camino wichtige Kernkomponente nicht mehr losgelöst von Firefox gibt. Der Camino-Code hat seinen Sitz immer noch in den von Mozilla gehosteten Sourcecode-Repositories, die Mozilla-Leute haben darauf also jederzeit unbegrenzten Zugriff, können sich bei Bedarf da bedienen, können ggf. Code wiederverwenden. Doch das wollen die gar nicht, weil der Camino-Code veraltet ist und aktuellen Ansprüchen nicht mehr genügt. Also schreiben sie den Cocoa-Code lieber neu und schneidern ihn auf aktuelle Bedarfe von Firefox und OSX zu, anstatt alten Camino-Code zu nehmen und den erstmal umständlich auf einen aktuellen Stand bringen zu müssen was moderne OSX-Anforderungen und -Frameworks angeht.

Wenn etwas bzgl. nativer Integration in Firefox bislang fehlt, hat das weniger damit zu tun, dass es nicht umsetzbar wäre, sondern vielmehr mit der Prioritätensetzung bei Mozilla und personellen Ressourcen. Da es ein für jedermann offenes Open-Source-Projekt ist, bleibt es Dir und mir und jedem anderen jedoch unbenommen, die fehlenden Features, die einem am Herzen liegen, dort per Patch einzureichen und seines zu tun, diese Lücke zu schließen. Die Mozilla-Leute freuen sich, sind sie dann davon entlastet und müssen's nur noch übernehmen.

Wenn Dir also was fehlt an Mozilla und Du diesen Zustand unhaltbar findest, dann: Auf auf! Ärmel hochgekrempelt und mitgeholfen, dass sich das ändert! Patch schreiben, auf Bugzilla einreichen, dafür werben, dass das möglichst bald in den Trunk gemergt wird, und schon hast Du Dein von Dir ersehntes Feature und hast gleichzeitig ein gutes Werk getan und auch andere Benutzer erfreut!
Mitmachen lohnt!

Viele der von Dir bemängelten Eigenschaften und Features sind bei Mozilla auf dem Schirm, haben auch einen entsprechenden Bug, haben evtl. auch schon einen passenden Patch, der das betreffende Feature implementiert, doch es bestehen Abhängigkeiten von anderen Bugs, deren Priorität möglicherweise auch noch höher eingestuft ist, oder der betreffende Entwickler arbeitet mittlerweile an etwas anderem, kann sich aus Zeitgründen da im Moment nicht so drum kümmern, wie es vielleicht für Dich und mich wünschenswert wäre bzw. es gibt evtl. andere Prioritäten, denen inzwischen Vorrang eingeräumt worden ist. Auf dem Schirm bei Mozilla sind diese Dinge jedenfalls alle. Teilweise, wie z.B. die PDF-Funktionalität mittels Rückgriff auf die nativ bereitgestellte PDFLib (mittlerweile durch pdf.js überflüssig geworden) oder die native Keychain-Integration (welche wunderbar funktioniert) per Add-On gelöst, weil eben Mozilla-intern die Prioritäten das derzeit nicht anders zulassen bzw. weil derzeit keiner frei ist, sich intensiv drum zu kümmern (deshalb: bei ausreichender Kenntnis sich ggf. als externer Entwickler anbieten, es zu übernehmen und einfach dann mal endlich fertigmachen und in den Trunk einpflegen, die Mozilla-Leute freuen sich über solche externe Zuarbeit, das ganze Projekt lebt, wie jedes andere gut geführte Open-Source-Projekt von solchen Beiträgen).

Solche Dinge sind also mehr also eine Zeit- und "Human Ressources"-Frage und damit eine Frage der Organisation und Prioritätenliste. Und keine technische Frage. Technisch zu lösen ist das alles. manchmal mit minimalem Aufwand. Aber es fehlen eben machmal die Leute, die Code in die Hand nehmen, welchen schreiben und es tatsächlich machen. Und Mozillas Firefox-Code ist kompliziert und schreckt viele ab.

Zudem gibt es halt weniger Mac-Entwickler (projekt-intern wie auch externe Mitmacher betreffend) als Windows- und Linux-Entwickler, die sich dann auch noch bereiterklären, mitzumachen und Code zu schreiben und beizusteuern. Und die stärkste Plattform mit der größten Reichweite ist immer noch (leider) die Windows-Plattform. Und nicht die Mac-Plattform. Dann ist es also auch klar, wie die Prioritätensetzung der Mozilla-Leute ist. Genau die gleiche Prioritätensetzung und Personal-Engpass gibt es auch z.B. bei Google. Oder was meinst Du, warum Chromium/Chrome auf dem Mac immer noch nicht 64bit-fähig ist (Chromium-Bug dazu: ), sondern noch mit 32bit dahindümpelt (und das deshalb mittlerweile zu einem echten Problem wird in Bezug auf Oracles geliefertes 64-bit-only-Java-Plugin und genau dieser Umstand jetzt den Google-Leuten etwas Feuer unterm Arsch macht und die Dringlichkeit/Priorität/Aktivität bzgl. dieses Bugs erhöht), unter Windows und Linux ein 64-bittiger Chrome-Browser aber schon längst umgesetzt und seit langem gang und gäbe ist?
Prioritätensetzung in der Abwägung zwischen personell zur Verfügung stehenden Ressourcen und dem zu erreichenden Publikum kraft Marktanteil.

Meiner Wahrnehmung nach indirekt schon, bzw. Du hast es meiner Ansicht nach insinuiert.
Sollte ich Dich diesbzgl. missverstanden haben, dann drück' Dich halt das nächste Mal klarer und unmissverständlicher aus.

Nein, ich meine schon Safari, darum habe ich das auch so geschrieben.

Und der Rest ist mir zu viel Text, sorry. Diktierst Du das alles?

Soll ich jetzt an jedes Wort Fußnoten machen, in denen ich alle ganz genau erkläre wie es zu verstehen ist?

In der Regel kannst Du davon ausgehen, dass ich meine Worte sehr wohl überlege, und dass ich genau das meine, was meine Worte aussagenlogisch hergeben.

Beispiel:
Wenn ich z.B. sage, dass ich auf der Website war, dann heisst es genau(!) das: nämlich, dass ich auf der Website war. Nicht mehr und nicht weniger! Es heißt nicht automatisch, dass ich sie auch gelesen habe, oder sonst was gemacht habe was man annehmen könnte, dass es geschehen sein sei. Davon kannst Du nur dann sicher ausgehen, wenn ich es auch explizit schreibe.

Alles klar?

Das gilt auch für alle andern hier, die mir ständig Aussagen unterstellen die ich nicht gemacht habe.

Was für softwaretechnische Klimmzüge müssen die Entwickler von Firefox da machen?!?

sry siehs einfach neutraler und schon sind wir auf der Ebene eines Programms, was auf verschiedensten OS s genau gleich funktioniert...Und so fallen OS spezifische Funktionen (wie die PDF Geschichte bei OSX) weg...

Umso mehr finde ich es sehr gut, daß Funktionen OS unabhängig eingeführt werden...was vieles erleichtern kann.

Und über OSX brauchen wir jetzt nicht reden. Das ist sowieso veraltet in jeder Hinsicht...
CoreAudio... alt... Opengl...super alt.... FileSystem... Ojeh das ist besonders veraltert...

Das es kein ZFS gibt verstehe ich nicht aber Apple und Sun (Oracle glaub ich) nicht geht war klar

Sehr geehrter Uhlhorn

Wir habens kapiert wie toll du den PDF Unterbau von OSX findest und so weiter... Du musst es nicht in jeder PDF bezogenen News aufs neue beweisen... Und wenn Adobe ihr Portable Document Format weiterentwickelt, dann wars das auch schon wieder. Also Adobe go for it... Kick Apple and go for forward....

Keine Ahnung was dein Problem ist oder das von "aa" (der Name sagt schon Vieles), aber der Uhlhorn bleibt im Vergleich zu dir sachlich, ruhig, gelassen und wird nicht gleich abfällig, nur weil er anderer Meinung ist als Andere...

Ich bin auch nicht abfällig...

Den einzig ironischen Part habe ich mit den Smilies richtig gekenntzeichnet und ja ich habs kapiert wie toll Gehard Uhlhorn den PDF Unterbau von OSX findet. Wenn der Wink zur Wiederholung abfällig ist? dann sry... da ich echt kein Problem damit habe.
Nur hier gings in den News ja um eine plattformübergreifende Vorschau von PDFs. Deswegen mein WInk, daß alle wissen, OSX kann das von Haus aus...

Also Sry, wenn das abfällg und schrecklich war...

Gerhard labert immer den gleichen Mist. Ein Apple-Fanboi vor dem Herrn. Sowas nervt. Ist ja nett, daß man in OSX so schön mit PDFs kann. Alles an OSX ist überragend. Sogar der mitunter veraltete Rotz an OSX ist überragend, nie dagewesen. Apple über alles, olee olee oleee. Und wenn man sich seinen anderen Müll so durchliest (freie Energie, Verschwörungstheorien, Homöopathie, ...), dann sieht man sehr schön wessen Geistes Kind er ist.

AppleUser2012: Ich habe mich hier gar nicht darüber geäußert wie ich den PDF-Unterbau finde. Ich habe nur das Problem mit Systemfunktionen und systemübergreifenden Programmen angesprochen. Also, wo ist Dein Problem?

Nun denn wenn

nicht das inpliziert und mehr noch, das OSX interne Framework hervorhebt, dann hab ich das echt falsch verstanden sry...

Ich hab kein Problem...