Hacker Newsnew | past | comments | ask | show | jobs | submit | hafta's commentslogin

The menu immediately closing was recently fixed[1] in Firefox 136. We'll look into the content of that menu not working correctly. Thanks.

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1935257


I've noticed that the default Firefox scroll speed is slower. As in the amount the page scrolls per rotation of the scroll wheel. This is a long shot, but do the settings here help in your case?

https://bugzilla.mozilla.org/show_bug.cgi?id=1388848#c32


Would you be able to file a Firefox bug on the DataView problem? Or if you have an example link we could look at that would be greatly appreciated.


There is this 6 year old and open report here: https://bugzilla.mozilla.org/show_bug.cgi?id=1065894

Chrome has improved DataView 2 years ago: https://v8.dev/blog/dataview

A rather basic jsperf is here: https://jsperf.com/dataview-float-int The results are that the u8 hack is equally slow in firefox and chrome (~90ops/sec), the DataView version is 10x faster in chrome(945ops/sec) but almost 4x slower in firefox(25ops/sec).


Thanks.


Thanks for bringing it up in the firefox issue tracker.


There's a bug filed for this.

"Bookmark toolbar items are harder to touch in the new megabar redesign"

https://bugzilla.mozilla.org/show_bug.cgi?id=1628243


> I replied sub-thread, but adding here to give some more visibility > to some of the issues DoH is causing and will cause: > > I work at a k12 school and I am involved on many k12 IT communities. > > Some schools already removed Firefox from the students computers > because it was being used as a "VPN" by some elementary students > to access porn - at school. Guess what this VPN was? Just DNS over HTTPS.

Firefox now has enterprise support where the administrator can force all desktops to use certain Firefox settings including enabling/disabling/configuring DoH.

See https://www.mozilla.org/en-US/firefox/enterprise/

And here's a link to details for configuration DNS over HTTPs. https://github.com/mozilla/policy-templates/blob/master/READ...

(I work at Mozilla)


> var BASE_ADR=zzzz;//Make BASE points to a random 256 bit currently uncached memory block that appplication has access to;

That should be 256 bytes.


yep, corrected. at the end it is a bit more complex than that as cache is populated in 32-128 bytes increments but I leave it out for simplicity


> How sure are you that you won't end up with a whole bunch of hot chocolate that nobody wants? What is the waste factor when the extra work is done unnecessarily?

This is one of the things telemetry data can be used for. We can include telemetry probes in the browser that tell us what percentage of the time users end up switching tabs after hovering. Then we can make informed decisions about whether the feature is worth the extra complexity (and CPU cycles) before any development work is done. As far as tailoring the feature to individual browsing habits, telemetry could inform whether or not that would be worth implementing.


And I guess this wouldn't be possible with opt-in telemetry?


Not reliably, as only power users will ever even consider opting into telemetry (or changing pretty much any setting for that matter). And power users generally have a much clearer layout of the tabs in their mind and will always go straight up and click, rather than ruffling through the tabs for a second. Or something like that. You get the idea, behavior here is simply different for power users and those are who you'll reach with opt-in telemetry.

Also has to be asked, though, what's the point in making this opt-in? Is it in any way sensitive information whether you click after hovering a tab? I also prefer being more cautious than is necessary, because sometimes there just is some privacy implication you didn't think of, but with this the risk seems incredibly low and they do have a clearly defined use for the telemetry.


If you have the time, please file a bug at https://bugzilla.mozilla.org/ it's pretty painless. We definitely care about Firefox on Mac. Thanks.


Would be great if you could start to care about Firefox on Linux, too. (It's the only platform where hardware acceleration is disabled for example https://bugzilla.mozilla.org/show_bug.cgi?id=1280523)


Yeah, it's really weird that you STILL have to force enable it through about:config. Come on Mozilla… Mesa 17 has arguably the best OpenGL implementation ever.


I can confirm that the 57 beta has acceleration enabled by default on Linux.


Are you sure? You need to check about:support, as the checkbox in the settings does nothing on Linux. It still says

HW_COMPOSITING blocked by default: Acceleration blocked by platform

for me with Nightly (57) on Linux.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: