News for hackers. Stuff that matters.
Re:Introducing a new HTML element – welcome <clippy> by JoshTriplett on Thursday June 13, 2019 @08:47AM (#20174240)
What aspect of the Firefox UI bothers you?
Re:Introducing a new HTML element – welcome <clippy> by sovande on Thursday June 13, 2019 @09:36AM (#20174684)
Not the OP, but I'll chip in with my $.02. I really want to like Firefox, but everything UI feels wrong (on macOS). From tabs, where the close button is on the wrong side (right) and if you click the + button to open a new tab the cursor ends up over the new tab, not over the + button so you can click again to open a new tab. The whole UI looks and feels non-native. Pressing ESC in full screen mode does not bring the window back to its original size. In-page search opens a clunky (javascript?) search field in the bottom status bar. Firefox does not support proper macOS dark-mode (try cmd-O). Cannot print to PDF. (Magic mouse) gestures does not work. No automatic keychain integration for login forms. Fonts are rendered different than in Chrome and Safari, e.g. thin fonts are tick and font's in general look more ugly (something with antialiasing?). The list goes on and on. Basically Firefox feels like browser version of Slack.
Re:Introducing a new HTML element – welcome <clippy> by riffraff on Thursday June 13, 2019 @11:36AM (#20175853)
> No automatic keychain integration for login forms.

Chrome also stopped doing this, AFAIK.

Fun fact: I was subscribed to a firefox ticket "Password manager should support OS X Keychain" which is 18 years old, it got closed some months ago. https://bugzilla.mozilla.org/show_bug.cgi?id=106400

Re:Introducing a new HTML element – welcome <clippy> by wlesieutre on Thursday June 13, 2019 @10:31AM (#20175222)
The other one that bugs me the most is lack of bouncy overscroll with my trackpad. Being used to that in the rest of the OS, it feels very jarring when you scroll up to the top of a page and it abruptly jerks to a stop.
Re:Introducing a new HTML element – welcome <clippy> by giancarlostoro on Thursday June 13, 2019 @10:32AM (#20175231)
> and if you click the + button to open a new tab the cursor ends up over the new tab, not over the + button so you can click again to open a new tab.

Same experience for me on Chrome on macOS too, so... You sure you didn't change those defaults somehow?

I usually open new tabs with Command + t or Control + t on Linux / Windows.

Re:Introducing a new HTML element – welcome <clippy> by eridius on Thursday June 13, 2019 @06:46PM (#20179273)
> From tabs, where the close button is on the wrong side (right)

Chrome does this.

> and if you click the + button to open a new tab the cursor ends up over the new tab, not over the + button so you can click again to open a new tab.

Chrome does this too.

> The whole UI looks and feels non-native.

Yep, that describes Chrome.

It sounds to me like you're a Safari user, since the things you're describing are things Safari does correctly. I'm a die-hard Safari user, and both Chrome and Firefox feel wrong to me. But Chrome feels even worse than Firefox does.

Re:Introducing a new HTML element – welcome <clippy> by solidasparagus on Thursday June 13, 2019 @12:53PM (#20176614)
I'm so confused. I'm on Chrome for mac right now and half of those things seem to not exist in Chrome either.

- The 'x' is on the right of every tab.

- When I press '+', the cursor ends up over the new tab - I cannot immediately click '+' again.

- Pressing esc does not do anything for full-screen mode.

Re:Introducing a new HTML element – welcome <clippy> by brianush1 on Friday June 14, 2019 @02:26PM (#20185382)
> From tabs, where the close button is on the wrong side (right)

In Firefox, using the Customize option from the menu, you can move the new tab button to the left side of the tabs, or even to the far right side so that it doesn't move.

Re:Introducing a new HTML element – welcome <clippy> by modzu on Thursday June 13, 2019 @11:16AM (#20175659)
agreed, the list is huge and so many of them seem like minor fixes -- for example the white flash that appears when opening a new tab in dark mode can be fixed with userChrome.css. its been an issue for a year. i don't know if mozilla is just broke or what, but it sure feels like their projects are hanging together by a thread. i still use it because i want them to succeed. i would be happy to work on it personally if mozilla would have me lol (instead ive made lots of extensions).
Re:Introducing a new HTML element – welcome <clippy> by hnaccy on Thursday June 13, 2019 @12:17PM (#20176293)
The close button has been on the left for years on mac?

What version are you using?

Re:Introducing a new HTML element – welcome <clippy> by mbreese on Thursday June 13, 2019 @08:56AM (#20174319)
I’m in the middle of trying this exercise now. Some of the differences are just getting used to new design.

For me the most jarring thing is how Firefox’s omnibar works. It isn’t good at showing me the sites I’m looking for after typing just a few characters. Instead, it shows absolutely every page I’ve recently visited at one of those sites.

Another design thing is the amount of information on the default new page has a ton more info than I’m used to seeing (or really want to see). Hence a question I posted yesterday:

https://news.ycombinator.com/item?id=20167192

On iOS, I keep trying to pull to refresh pages, but in Firefox it’s a specific button. But this is something that I could get used to.

Re:Introducing a new HTML element – welcome <clippy> by JoshTriplett on Thursday June 13, 2019 @09:08AM (#20174428)
> For me the most jarring thing is how Firefox’s omnibar works. It isn’t good at showing me the sites I’m looking for after typing just a few characters. Instead, it shows absolutely every page I’ve recently visited at one of those sites.

Interesting! I think this may be a case where, over time, as you use a search mechanism, you get used to the kinds of searches that work well with that mechanism. I've had similarly frustrating experiences with Chrome's address bar, which I'm not used to using.

Firefox has a concept of "frecency", a metric that combines frequency of visit and recency of visit to determine what you're most likely to want based on what you typed. (It also gives some preference to the starts of words/domains, and some other heuristics.) However, I can easily believe that before Firefox has enough information, typing at it would produce suboptimal results. That's something worth reporting as a bug: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&c... . Please feel free to use any of the text above to help describe the issue, if it helps.

> Another design thing is the amount of information on the default new page has a ton more info than I’m used to seeing (or really want to see).

Complete agreement. I disable the new tab page on desktop, as I really just want a blank page. (On mobile, I find the default new tab page more useful and usable.)

Re:Introducing a new HTML element – welcome <clippy> by Aeolun on Thursday June 13, 2019 @09:27AM (#20174611)
When I type in ‘news.’ Firefox still gives me ‘hackernewsgrid.com’ as the first result, even though I haven’t visited that page in years, and in fact it is completely down.

I’m not sure how the omnibar works, but I’m not extremely impressed.

Re:Introducing a new HTML element – welcome <clippy> by mbreese on Thursday June 13, 2019 @09:38AM (#20174697)
When I type “n”, I’m likely either going to news.google.com or HN. Firefox will guess correctly that I’m thinking of HN and fills that in as the URL. However, the main HN URL and Google News are something like 8 and 9 in the list. Everything above those two is a mix of things that happen to have an “n” somewhere in the URL that I may have recently visited.
Re:Introducing a new HTML element – welcome <clippy> by brianush1 on Friday June 14, 2019 @02:31PM (#20185423)
As the grandparent comment says, you just get used to how Firefox works. For example, I would've never even thought to type "news" to look for hackernews in the omnibar after using it so long-- I just instinctively know that Firefox will find it easier based on domain name, so I type "yc" for "ycombinator.com"

I can see how this is going to be confusing for a new Firefox user, but it's easy to get used to.

Re:Introducing a new HTML element – welcome <clippy> by mbreese on Thursday June 13, 2019 @02:37PM (#20177486)
Note: this is different b/w the desktop and iOS versions too. The desktop seems to have gradually gotten better as it’s been trained more.

(And I have Firefox sync setup)

Re:Introducing a new HTML element – welcome <clippy> by amluto on Thursday June 13, 2019 @11:23AM (#20175737)
Type ‘news’, use the arrow keys to select the offending entry, and hit delete.
Re:Introducing a new HTML element – welcome <clippy> by eitland on Friday June 14, 2019 @01:02AM (#20180700)
Just type news<space>y then until it gets used to it.

(And on a general note: some people here might want to verify they haven't touched the settings;-)

Re:Introducing a new HTML element – welcome &lt;clippy&gt; by wrycoder on Thursday June 13, 2019 @10:42AM (#20175326)
I have several sites that I visit daily. All of them can be accessed by typing in the first character, or, at most, two characters - the url then appears in the navbar, just hit <enter>.

The strange thing is, every nine months or so, FF will forget one of these urls. It doesn't do it for all of them at once, just one, and it's not related to upgrades. All I have to do is enter the full url and hit enter, and things are back to normal again for that particular url for many months.

Re:Introducing a new HTML element – welcome &lt;clippy&gt; by thomasedwards on Thursday June 13, 2019 @09:07AM (#20174419)
Not the OP of that comment, but I feel the same way.

I use macOS, so maybe it’s different on Windows. A few things bug me, it’s hard to really pin it down. It just doesn’t feel finished. The Save File dialog window feels like it’s from Mac OS 9, or at least its sentiment is. The behaviour is confusing, because if you press cancel, you still end up with a file in you Downloads. It would better if it just dealt with it the way Safari and Chrome do. A lot of the dropdowns and other inputs feel a little old too, everything ends up looking like 2003, which isn’t terrible, but I would imagine it puts people off when switching from Chrome.

The address bar is also very odd, it almost always suggests the wrong thing for me. I’ve adjusted the settings, but even for a site I just visited with the exact name in the page title, I still end up with the search as the default result.

Re:Introducing a new HTML element – welcome &lt;clippy&gt; by JoshTriplett on Thursday June 13, 2019 @09:10AM (#20174445)
That's some very reasonable feedback. Please consider reporting those as issues (the latter perhaps coordinated with the other commenter's bug report). Emphasize that it substantially affects the first-time user / new user experience; that may help get appropriate attention.
Re:Introducing a new HTML element – welcome &lt;clippy&gt; by nonbirithm on Thursday June 13, 2019 @01:01PM (#20176705)
The search bar in Firefox always assumes you're attempting to visit a URL if you type two words separated by a dot. It's incredibly frustrating trying to search things like "table.sort" and being redirected to a URL that doesn't resolve to anything and will almost certainly not for a while. Chrome doesn't have the same behavior (it ships with a list of valid TLDs). I get that you can work around it easily by typing a space, but the habit is ingrained for me due to switching from Chrome and this alone makes me want to switch back, if not for the desire for Mozilla to succeed. There is a bug for this issue[0] which has been open for 5 years.

For FF mobile the UI is less convenient than Brave. In Brave the icons for adding a new tab and switching tabs are at the bottom of the screen, while in FF they're in a menu at the top. Because I use my phone in portrait mode I have to reach my thumb up to the menu every time to create or switch tabs. It's really tiresome and I use Brave instead due to this. Also, the URL bar on mobile FF has the 'X', but its behavior is completely different from Brave. It closes the bar entirely rather than clearing it. I also get that it's a thing to get used to after switching, but why not just delegate cancellation to the Android back button? (Could it be due to iOS?)

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1080682

Re:Introducing a new HTML element – welcome &lt;clippy&gt; by rurp on Thursday June 13, 2019 @03:02PM (#20177692)
One Firefox option I love but don't see used much is the optional search bar you can add next to the url bar. I MUCH prefer to use that for searching for two main reasons:

1. It always "just works". I've run into problems with both Chrome and Firefox getting confused by a search term I entered into the URL bar.

2. The search string persists even after clicking on results. This is particularly helpful when I'm having trouble finding a good result and want to make a slight change to my previous search string, or I want to remember exactly which search term brought up a specific result.

Re:Introducing a new HTML element – welcome &lt;clippy&gt; by mwcampbell on Thursday June 13, 2019 @10:10PM (#20180099)
> "table.sort"

Just curious, are you developing in Lua? That would be my guess from that string.

Re:Introducing a new HTML element – welcome &lt;clippy&gt; by nonbirithm on Monday June 17, 2019 @09:03PM (#20208921)
Yes, I am actually. I'm trying to rewrite a game's codebase to use LuaJIT/LOVE for modding support.
Re:Introducing a new HTML element – welcome &lt;clippy&gt; by OnlyOneCannolo on Thursday June 13, 2019 @11:08PM (#20180323)
Simply put: There's too much of it.

Chrome is dead simple, minimal, and predictable. When I want something, I look in the one menu. Firefox, on the other hand, has multiple bars, multiple menus, sidebars, icons plus text. It's too much.

Re:Introducing a new HTML element – welcome &lt;clippy&gt; by finchisko on Thursday June 13, 2019 @09:31AM (#20174641)
What bothers me, are dialogs and windows not written in html and css (not sure what it is, maybe XUL?). Chrome basically eats it own dog food = everything is html. Firefox still has settings done in non html way. It may sound marginal problem to you, but IMO browser should be showcase for html and html should be used everywhere. Also amount of popup dialogs/windows should be reduced. Again settings, about, ... should be html page, instead of popup window, which cannot be until it's rewritten as html page (so it's related to my first point).

FYI: I use Firefox for idealogical reasons.

Re:Introducing a new HTML element – welcome &lt;clippy&gt; by millstone on Friday June 14, 2019 @04:52AM (#20181444)
UI elements written in HTML are hella buggy. For example, Chrome's hamburger menu (I don't know if it's written in HTML but it sure feels like it):

1. Spacebar doesn't select items

2. Key equivalents don't work while it's open

3. Cut/Copy/Paste often does not work, depending on where the keyboard focus is

4. Inapplicable menu items don't disable properly

5. The caret continues blinking in text fields even though keyboard focus is in the menu

etc etc. This sort of basic bugginess is embarrassing and entirely avoidable by using the native platform controls, instead of re-inventing them poorly.