ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
54% Positive
Analyzed from 2465 words in the discussion.
Trending Topics
#browser#firefox#pdf#mozilla#why#https#html#page#browsers#years
Discussion (63 Comments)Read Original on HackerNews
Interesting that they just buried this in the middle without even a screenshot, considering how hostile Mozilla has been to the proposal in the past[0].
Considering that they previously made quite strong arguments that implementing QWAC would undermine security by completely bypassing the existing CA trust process and violate user's privacy by leaking browsing activity to third parties: what changed?
It does seem to fit into a wider movement, though. Mozilla previously explicitly considered WebUSB, WebHID, and WebMIDI as "harmful" as they lacked an effective mechanism against hostile websites tricking users into permanently compromising their hardware. This switched to "neutral" without addressing the underlying issue, seemingly just to satisfy some users asking for parity with Chrome out of a convenience argument. Same with Firefox happily jumping onto the AI bandwagon, and only backtracking after major public outcry.
Not to be dramatic, but Firefox seems hellbent on rapidly turning into a reimplementation of Chrome, completely ignoring its raison d'être. Will there be any traditional user-serving browsers left a few years from now?
[0]: https://s3.documentcloud.org/documents/21330628/mozilla.pdf
[0]: https://securityriskahead.eu/
You can rest assured that Mozilla will never copy Chrome's updating the mouse coordinates during dragstart, drag and dragend events.
"the spec doesn't specify what the properties should be set to, just that they should be set and we currently set them to 0."
https://bugzilla.mozilla.org/show_bug.cgi?id=505521
16 years and no sign of a resolution. I look forward to celebrating the day that bug becomes old enough to split a six pack with me.
Edit: It was first filed on July 21, 2009 so it will soon be 17.
One can hope that by then Ladybird has landed. There was some rumblings about an alpha release come 2027 so "few years" might actually be achievable if the speed remains constant.
Well... millions of Chrome users played guinea pigs for WebUSB and the security issues proved to be theoretical in the end, while (particularly in the Arduino/ESP32 community) more and more people were pissed off at the lack of these features in Firefox.
But, if Mozilla wanted to acquiesce, they could release an EU-only version instead of weakening the trust/security of their browser for everyone.
Also, imagine the backlash that would happen if some part of the United States executive branch demanded the same thing the EU is demanding here.
Complying to the exact letter of a stupid law to avoid getting sued is understandable. Voluntarily complying to the broadest interpretation without any pushback is not.
> It is now possible to add images as new pages within PDFs using the Firefox PDF editor.
I have always found it odd that browsers are also PDF editors increasingly.
That said, I'll pick the in-browser tools over Adobe Reader every time.
The problem is the edge cases. PDF has lots.
In $DAYJOB-1 we used PDFs as part of the official feedback process for technical documentation: subject-matter experts sent their comments as PDF annotations. Most FOSS viewers can't show them.
Form filling also is a tricky area. Conversion, searching, accessibility tools (screenreaders often can't read PDFs), comments, annotations, editing, all these and more are significant functional weaknesses for the free viewers.
That's setting aside the really fancy stuff, like 3D objects, video, media content, etc.
Even so PDF viewers are big and complicated things so smaller distros pick up tools from alien desktops -- e.g. KDE's Okular, which I find fugly but can handle comments, or GNOME's weird crippled UI in Evince or Papers, with no menu bars etc., but which is Gtk so you find it in many Gtk desktops.
It wasn't hard for the Firefox viewer to outdo 90-95% of the free viewers because the free viewers only do the dead basic stuff, and that kept Acrobat Reader alive on other OSes -- even though the last Linux one is version 9, from 2008.
But for general document reading, Reader's UI has been awful for years. The amount of unnecessary toolbars, popups, upsell offers, and (recently) AI assistant recommendations pile up and block the one thing I actually want the app to do.
So that feels fine (assuming it runs in same sandbox like any page), just bundled HTML/JS being changed.
Not true. The original Mozilla Internet Suite was a combined browser, email/newsgroups client, and web-page editor. It was an open-sourced version of Netscape Communicator which did the same things. Seamonkey is the modern fork.
Firefox is the result of a project to cut down the Mozilla suite to something smaller, simpler and more focused, but its parent program and direct ancestor edited text, HTML, and did other read/write stuff like messaging, calendaring, etc.
So this seems to make a lot of sense to me and I'll be glad to have the functionality, especially when PDF functionality is such a mess in the general world (lots of barely-working software).
https://blog.whatwg.org/the-road-to-html-5-contenteditable
Edit: yes it does - perfect!
I have a PDF that I can't view at all.
And regardless of logical fit for geeks (who understand the paragraph above), users clicking a .pdf URL may find it much more convenient if it just opens in their browser like any other http page, rather than downloading, opening in another window, getting lost between the MDI browser and separate SDI of the PDF file, etc. Why not treat PDF as just another web format?
To me, more strange is Firefox adding PDF editing features to its core, rather than as add-ons. Users can't edit HTML or any other media without extra tools. Many pdf reader apps can't do some of these things (afaik). Why invest developer time in PDF editing?
- why dont any of the modern browsers open and load pages instantaneously anymore, why does it take seconds?
- is this because of backward compatibility support where you are supporting html, css and JS features all the way back to the 90s
- apart from gecko and v8 why dont we have browser engines?
- are you familiar with anyone building an entire browser engine from scratch? how many WhatWG specifications would they have to support
- with all the GPT hype of late, why havent we seen a single GPT yet capable of building a browser engine from scratch supporting the last 20 years of html, css and js specs?
Right click > Inspect. Go to the "network" tab, reload the page. Maybe do the same on the "performance" tab.
Ladybird [1] is exactly that. Started as browser for the SerenityOS project [2] but ended up being spun off as its own project.
[1] https://ladybird.org/ [2] https://serenityos.org/
Macsurf is a browser project for Mac OS 9 leveraging LLMs[1] to do this. Tbh it makes sense for this given how time-consuming (absurd? Though the fact it exists tickles me) it'd be otherwise for essentially a single person to support the scope of web tech it does for such an incredibly niche userbase.
[1] https://news.ycombinator.com/item?id=48339534
If we are talking about a blog page, just a static html - it should take some ms. No problem here.
But if we are talking about some heavy pages and fetch requests to other places, well...
Or simply a page with f 10Mb header image.
>apart from gecko and v8 why dont we have browser engines?
gecko (Firefox), blink (chrome and friends), webkit (Safari, Kagi and some other, mostly linux distro browsers) are the only stable ones. Servo and Ladybird are on the way, but it will take quite some time for them to mature.
>are you familiar with anyone building an entire browser engine from scratch?
Ladybird. No idea about specifications.
>with all the GPT hype of late, why havent we seen a single GPT yet capable of building a browser engine from scratch supporting the last 20 years of html, css and js specs?
Well, aside from the fact that this will be a one expensive project - you (someone) will have to test this code anyway. Also this: https://ladybird.org/posts/changing-how-we-develop-ladybird/
You mean apart from Gecko and Blink (v8 is a JS engine, not a browser engine.)
But we do, for open source engines we also have WebKit and NetSurf and some others.
https://endtimes.dev/why-your-website-should-be-under-14kb-i...
It's also planned to integrate the ability to assign a website to a specific container. There's no information available on the other extra features from Multi-Account Containers like VPN/Proxy per container for the moment.
You can follow the development on bugzilla https://bugzilla.mozilla.org/buglist.cgi?component=Container...
[1]: https://support.mozilla.org/en-US/kb/how-use-firefox-contain...
What's new here? Containers have been an add-on, at least, for a long time? Is it integrated into core Firefox for the first time?
> Quickly pick and copy a color from any page by typing "pick color", "color picker", or "eyedropper" in the address bar and selecting the "Pick a color" quick action.
This seems like add-on or developer tools territory. Maybe that's what quick actions are? Does Firefox really want to add non-essential widgets to maintain, support, and integrate going forward? Maybe this one is necessary for some reason? I have a global color-picker that works in every application; I expect many who need one have the same.