[HN Gopher] Use native context menus on Mac OS
___________________________________________________________________
Use native context menus on Mac OS
Author : reid
Score : 550 points
Date : 2021-05-25 06:57 UTC (16 hours ago)
(HTM) web link (bugzilla.mozilla.org)
(TXT) w3m dump (bugzilla.mozilla.org)
| mtlynch wrote:
| This is a fun comment:
|
| > _Blake Ross_
|
| > _Comment 5 * 21 years ago_
|
| > _How easy /hard would this be?_
|
| Blake Ross[0] was 15 years old at the time of that comment. It
| was two years before he, Dave Hyatt, and Joe Hewitt published the
| first version of Firefox.
|
| [0] https://en.wikipedia.org/wiki/Blake_Ross
| DonHopkins wrote:
| He even wrote his own fanfic episode of Silicon Valley!
|
| https://techcrunch.com/2015/09/04/the-founder-of-firefox-wro...
| ksec wrote:
| I _think_ he is at Uber now, not sure if that is still the
| case.
| pjc50 wrote:
| Every now and again I get an email about a bug I commented on
| sixteen years ago that was opened 21 years ago:
| https://bugzilla.mozilla.org/show_bug.cgi?id=57342
|
| It's kind of nice to see that they will, eventually, get round to
| issues like this.
| cannam wrote:
| Comment in December 2000:
|
| > Yes, WONTFIX and INVALID seem a bit much. We'll just keep it
| in the database for eons.
|
| That joke aged exceptionally well!
| jenshk wrote:
| But but.... There is no data. There is only XUL
| thih9 wrote:
| Impressive! I like how this makes the browser's UI simpler and
| more predictable.
|
| Also, this is especially useful for people using dark mode, since
| native context menus match that setting.
| mhd wrote:
| Ah, "native" and "firefox" really makes me miss Camino, which was
| a pretty great mix between OS X standard UI features and the FF
| rendering engine. But apparently keeping that up to speed with
| Firefox main releases was way too much effort (probably one of
| the reasons why there are plenty of webkit/chrome shells and
| almost no Firefox ones).
| classichasclass wrote:
| The big reason was that Mozilla ended embedding Gecko with
| Firefox 4/Mozilla 2. This made it nearly impossible to run
| Gecko in anything but an XUL shell. I understand the reasons
| cited at the time, largely available resources, but it was very
| short-sighted and I think it hurt Gecko's mind shares in the
| long run.
|
| I loved Camino as well. A truly excellent browser.
| kitsunesoba wrote:
| Gecko ending embedding is almost certainly a major reason why
| everything built with a browser engine is either a Chromium
| wrapper (not true embedding, but no browser chrome) and
| WebKit (true embedded).
|
| It's a real shame. Gecko is a nice engine but XUL is a much
| harder sell.
| cpmsmith wrote:
| Servo is the theoretical successor in this regard, like so
| many other regards, right?
| iFreilicht wrote:
| Is the goal of Servo to replace Gecko eventually? I
| thought it was more of a testbed for new rendering
| techniques.
| classichasclass wrote:
| Correct. It's not intended as a Gecko replacement, and
| several important components in Servo are already part of
| Gecko. Servo will continue to evolve and new features
| will originate from it, but it lacks a lot of the legacy
| and quirks rendering (intentionally) that would be
| required to make it a full-fledged engine of its own even
| if Mozilla wanted it to be.
| grouphugs wrote:
| why would anyone still use an alt-right product from a fascist
| corporation that would never respect their privacy? you people
| are fucking retarded
| wodenokoto wrote:
| Not having the "Look up ..." available from the context menu is
| my biggest pet-peeve with Firefox on MacOS.
|
| I know you can force-click on laptops, but, not everyone is on a
| laptop all the time, and force-clicking doesn't allow you to
| choose the selection, which can be quite problematic for
| languages that doesn't use spaces.
| max1cc wrote:
| Using Firefox now, making a selection and then force-clicking
| it opens it in Look Up
| wodenokoto wrote:
| You are right. That must be pretty new. Thank you for letting
| me know - this is really useful for me!
| Aeolos wrote:
| This was available in my late 2017 macbook pro with force
| touch. I know because I don't like this feature and was
| searching for a way to disable it.
| wodenokoto wrote:
| Didn't work on Japanese text for me just a few months
| ago. 2018 MacBook Pro.
| Yaina wrote:
| You could file a bug for that! The macOS team at Mozilla is
| trying to make changes to be a better mac citizen (see native-
| context menus) :)
| richardwhiuk wrote:
| Already open -
| https://bugzilla.mozilla.org/show_bug.cgi?id=1116391
| seumars wrote:
| Looking forward to 2042!
| DonHopkins wrote:
| I have always wanted to implement pie menus as a Firefox or
| Chrome extension, but I've never been able to find a sufficient
| API that enables me to pop up a modal dialog window at any place
| on the screen (specifically: centered on the current mouse cursor
| position, and in an operating system window that exists outside
| of the browser tab, overlapping all other windows). Or reshape it
| to any shape (or simply respect the alpha channel of the document
| and not show any chrome), so I can make a round or arbitrarily
| shaped window shrink wrapped to the items.
|
| https://developer.chrome.com/docs/extensions/reference/windo...
|
| Is there a way with that (or any other) API to pop up and
| precisely measure and position an arbitrarily shaped (alpha
| channeled) window, without any other chrome or window frames? And
| then globally capture and track mouse and keyboard events?
|
| Does anyone know if there's now a way for a browser extension to
| do that in any browser? Or would it require hacking platform
| specific C++ operating system code?
|
| Here's a demo of an ancient implementation of pie menus I made
| for ActiveX around 1997, that shows pie menus with arbitrarily
| shaped windows:
|
| ActiveX Pie Menus: Demo of the free ActiveX Pie Menu Control,
| developed and demonstrated by Don Hopkins.
|
| https://www.youtube.com/watch?v=nnC8x9x3Xag
|
| ActiveX Pie Menus doc, examples, sources, etc:
|
| https://www.donhopkins.com/home/catalog/piemenus/ActiveXPieM...
|
| https://www.donhopkins.com/home/catalog/piemenus/PieMenuDesc...
|
| I did all the drawing with Win32 calls, so you could configure
| the fonts and colors and sizes and window shapes and styles, but
| you couldn't style everything arbitrarily with css, embed
| arbitrary web content, or anything nice like that.
|
| At the end of the demo video, I concluded that:
|
| >I ran up into a wall of complexity with this ActiveX control, in
| that I wanted to be able to have as the menu items animated gifs,
| mpeg movies, fonts with nice attributes, and things like that.
|
| >So the first thought was "well let's just put a whole web
| browser in every item!"
|
| >But that was a little heavy-handed. So instead, I put the pie
| menus into the web browser as a Dynamic HTML Component. Which
| I'll show next.
|
| Of course it makes a lot more sense to draw and style the pie
| menus with the browser's renderer, but I still want the best of
| both worlds, where I can pop browser-drawn pie menus in
| arbitrarily shaped and positioned operating system windows, and
| track the mouse globally (capturing the mouse and keyboard events
| and receiving mouse motion and up and key events outside the
| window, to pop up and track sub-menus properly).
|
| JavaScript Pie Menus: Pie menus for JavaScript on Internet
| Explorer version 5, configured in XML, rendered with dynamic
| HTML, by Don Hopkins:
|
| https://www.youtube.com/watch?v=R5k4gJK-aWw&ab_channel=DonHo...
| aasasd wrote:
| You'd probably want to use 'native messaging' from the
| extension for this: https://developer.mozilla.org/en-
| US/docs/Mozilla/Add-ons/Web...
|
| I think it's sufficient to override the 'contextmenu' event and
| signal to your app where to show the menu and what to show in
| it. You can even implement the menu itself in something like
| Hammerspoon on Mac, with Lua APIs--dunno about Linux. However
| you'll have to define the whole menu yourself, since you don't
| have info on the browser's one.
|
| Though it might possibly be easier and more performant to have
| websocket communication with the app--it means the app will
| have to stay open, but that's not much of a problem in this
| case. OTOH I'm not sure that browsers won't start blocking
| requests to localhost servers, after the privacy issues.
| Bigpet wrote:
| I always thought that the "marking menu" style in Maya was
| always a neat implementation. Keeping the traditional context
| menu to not alienate regular users, but offering radial and
| gesture style navigation was really a great choice for its
| niche.
|
| A power-user software that makes heavy use of mouse
| manipulation is perfect for those kind of "enhancements" of
| traditional ui elements.
|
| The marking menu style made the learning was more pleasant than
| let's say the very keyboard shortcut heavy interface of
| Blender. But I feel like after struggling a while with the
| shortcuts, using Blender felt faster after the learning curve.
|
| So maybe there's some niche between expert systems and beginner
| friendly apps or in embedded devices where such "intermediate
| UI" solutions are better at home.
| aasasd wrote:
| It seems this is the 'marking menu':
| https://lesterbanks.com/lxb_metal/wp-
| content/uploads/2014/02...
|
| But it looks pretty dubious from the perspective of Fitts'
| law. The items to the left and right are vaguely okay-ish:
| they're long in the direction of cursor movement, however you
| need to hit the narrow vertical profile while there's empty
| space above and below each item. The top and bottom items,
| though, are narrow in the direction of cursor movement while
| being far enough from the mouse that the movement will have
| some speed. It's the same problem as Windows' menus have,
| only closer to the mouse so not that pronounced.
|
| Meanwhile, in a classical radial menu, the items are closer
| to the cursor and they should have considerable depth in the
| dimension of cursor movement if they use icons of non-
| microscopic size.
| lumpa wrote:
| I remember using something like this in Firefox a long time
| ago. A search suggests it was Optimoz/RadialContext:
| http://www.mozillazine.org/talkback.html?article=2407
|
| There's at least a current attempt at the same idea, posting to
| test it later: https://addons.mozilla.org/en-
| US/firefox/addon/easygestures-...
| dijit wrote:
| The common practice now is to "close stale issues", which was
| discussed recently, though I can't find the thread.
|
| It's nice to see the inverse of that, I doubt anyone would have
| replied every 90 days for 21 years.
| shrx wrote:
| > The common practice now is to "close stale issues", which was
| discussed recently, though I can't find the thread.
|
| Maybe this? https://news.ycombinator.com/item?id=26590961
| WhyNotHugo wrote:
| A common practice is to also LOCK stale issues, disallowing any
| further discussion.
|
| IMHO, it's a terrible practice, since it pushes for infinite
| duplicates completely losing the trail of previous discussion.
| chrismorgan wrote:
| Closing issues automatically after a certain period of time is
| a disastrously stupid thing to do for a bug tracker that helps
| _no one_ (not users, not reporters, not maintainers), and is
| actually _counterproductive_ in systems where search excludes
| closed issues by default (which is most of them), because
| you're certain to end up with more duplicates.
|
| There are other types of trackers where automatic closure can
| be justified, but a bug tracker is _not_ one of them.
|
| I've said it before and will keep on saying it: GitHub's stale
| bot should be removed with prejudice.
| Jenk wrote:
| Meh. It's just a method of filtration.
|
| When you can only tackle so many things there is 0 point in
| having a bug tracker that will only inflate and with little
| in the way of automatic triage determining the priority it is
| a borderline impossible task to wade through them.
|
| Allowing duplicates is fine, the important stuff comes up
| again whilst the unimportant bits die off.
| MayeulC wrote:
| > Allowing duplicates is fine, the important stuff comes up
| again whilst the unimportant bits die off.
|
| You lose a lot of context from other reporters, and some
| discussion that could happen between reporters. All of this
| allows diagnosing an issue, and sometimes solving it
| without input from the team ("ah, this 3 years old bug? I
| solved it, turns out I had faulty memory, check yours").
|
| I dislike closing them, especially as github only has two
| states: open and closed, and doesn't distinguish with
| invalid, wontfix, fixed, stale, needinfo, etc.
|
| At least they are still searchable and interactable with
| when closed, but who thought it was a god idea to lock
| them? All the original subscribers won't be notified of new
| discussion on the topic.
| Jenk wrote:
| AFAIK when a closed/locked issue is referenced, watchers
| get notified. If they don't I agree they should.
| MaxBarraclough wrote:
| > Meh. It's just a method of filtration.
|
| No, it's a method of automatically discarding valuable
| information.
|
| To put a different spin on what TeMPOraL said: a bug is
| roughly defined as _a deviation from expected program
| behaviour_. It is not defined as _a deviation from expected
| behaviour which we intend to fix soon_. There is value in
| keeping track of all the bugs in a codebase, even the ones
| you don 't intend to fix soon.
|
| That is to say, a bug tracker is for tracking bugs. It is
| not a to-do list. ( _edit_ Although I wouldn 't want items
| on my to-do list to expire without my knowledge, either.)
|
| If you want to mark a reported bug as _Not a bug_ or _Won
| 't fix_, that should be done manually. If a bug was fixed
| in passing as a result of some other work, the bug should
| be manually marked as fixed. It doesn't make sense to have
| a timeout act as a stand-in for a triage decision, in a way
| that fails to distinguish between these two outcomes.
| Jenk wrote:
| > No, it's a method of automatically discarding valuable
| information.
|
| So.. a filter.
|
| I didn't claim it is a perfect filter. I did claim it is
| _a_ filter and one may subjectively decide it is a better
| choice than trying to track an ocean of issues which, if
| you're someone the size of Mozilla, will be a vast
| majority of "It crashed" useless issues anyway.
|
| _If_ something is that important, it will come up again
| and closed issues can be referenced. Again, no claim that
| this is perfect from me.
| tinus_hn wrote:
| It's fine, as long as the time he submitter spent to write
| a decent bug report is worthless to you.
| frereubu wrote:
| That's a straw man. It's a balance between your time and
| theirs, and I presume you don't think that all bug
| reports are carefully considered and well-written. Many
| are even obtuse, aggressive and self-entitled. I'd bet
| most well-written, civil bug reports are at least taken
| seriously, even if they end up as a wontfix.
| ForHackernews wrote:
| There's nearly zero cost to leaving a stale bug report
| open. A few kB, and maybe not even that because closed
| tickets are rarely actually deleted.
|
| If you're not working on a bug, then, by definition, it's
| not taking up your time.
|
| Some people are just obsessive about not wanting to _look
| like_ they have open bugs on their project. But closing
| tickets and fixing bugs are not the same thing.
| thaumasiotes wrote:
| > But closing tickets and fixing bugs are not the same
| thing.
|
| You can't measure how many bugs you have, but you _can_
| measure how many bug reports you have. ;D
| marcosdumay wrote:
| > There's nearly zero cost to leaving a stale bug report
| open.
|
| Triaging an endless list is very costly.
|
| I do agree with the idea that if you expect your project
| to be public (and not just something you did that you'll
| share if somebody wants) it is a cost you are expected to
| take. But it's wrong to pretend it's free.
| oooooooooooow wrote:
| Triage is what happens when you first look at a new
| ticket and decide what to do with it, any
| encounter/interaction after that is not a triage.
|
| If maintainers feel like they need to close tickets only
| to keep order, than that's a problem with the tooling:
| tickets should only be closed if they're malformed,
| solved, or (arguably) wontfix.
| marcosdumay wrote:
| > If maintainers feel like they need to close tickets
| only to keep order, than that's a problem with the
| tooling
|
| Oh, yes. Yes it is!
|
| I think you were downvoted because the first part of your
| answer is wrong, but this one hits right on the mark.
| Jenk wrote:
| Priority is a constantly moving slide.
| tinus_hn wrote:
| You don't need to wait for a certain period of time to
| decide that a bug report is poorly written.
| TeMPOraL wrote:
| > _When you can only tackle so many things there is 0 point
| in having a bug tracker that will only inflate_
|
| A public bug tracker isn't just for you. It, arguably,
| isn't even _primarily_ for you. It 's for all your users
| who experience a problem and want to confirm if someone
| else also had it, and if there's a known solution.
|
| (It's something that particularly annoys me as a developer.
| I can fix problems on my own just fine, thank you. But I
| want to know if my problem is something tied to my
| configuration, or a known issue of some software that's
| failing for me - so that I don't waste time looking for the
| cause in the wrong place. I want the project's issue
| tracker to help me answer that question quickly - and auto-
| hiding/archiving/closing stale issues makes this job much
| harder.)
| toyg wrote:
| _> A public bug tracker isn 't just for you. It,
| arguably, isn't even primarily for you._
|
| There is a lot of work still to be done on bug-tracking.
| The eternal attempt to keep users away from bugtrackers
| has meant that, when they inevitably became public
| because of FOSS growth, their interfaces did not really
| work for users.
|
| I think it's high time we accepted bug trackers are also
| forums. There should be a way to mark certain comments as
| "effective workaround", and surface them at first glance.
| There should be ways for developers to mark certain
| comments as "useful info" so that the rest can be
| filtered. There should be ways to have lengthy
| discussions attached to the bug but not forced on the
| developer. There should be incentives to actually solve
| "historical" bugs first. In short, there should be
| different ways to look at a bug depending on one's role,
| without losing anything, without alienating anyone, and
| accepting the complexity of user-developer relations.
|
| But there is very little money in it, I guess.
| rectang wrote:
| > _There should be a way to mark certain comments as
| "effective workaround", and surface them at first
| glance._
|
| Is there a reaction emoji that signals "effective
| workaround"?
| TeMPOraL wrote:
| We need a "duct tape" reaction emoji.
|
| Come to think of it, we need a "duct tape" _emoji_. I 'm
| surprised it isn't in Unicode already.
| Jenk wrote:
| There's this one in the extended block: https://www.filef
| ormat.info/info/unicode/char/1fa79/index.ht...
| TeMPOraL wrote:
| Close enough. That's arguably even better to represent a
| workaround.
| handrous wrote:
| PHP's _documentation_ allowed (allows? Not sure anymore)
| comments. Especially in the pre-StackOverflow days, this
| was absolutely brilliant. I 'm sure that's a pretty heavy
| moderation burden for any successful language (especially
| these days, maybe not as much when PHP's docs first added
| that feature) but damn it's nice.
|
| I love the idea of bugtracker-as-forum (you're right that
| they already are and we're just in denial about it and
| don't design them to do that well) but it's the kind of
| thing that doesn't seem productizable (how many companies
| would want that, for instance? I doubt many) and non-
| commercial non-trivial open source isn't such a lively
| field, lately.
| rkeene2 wrote:
| As an example of this, the SQLite bug tracker [0] is
| closed for submissions from non-developers (or some set
| of trusted people), and instead the SQLite forum [1][2]
| is used to discuss possible bugs.
|
| [0] https://www.sqlite.org/src/reportlist [1]
| https://www.sqlite.org/src/wiki?name=Bug+Reports [2]
| https://www.sqlite.org/forum/forum
| TeMPOraL wrote:
| That's a great perspective. I agree with what you wrote
| here.
|
| With that in mind, I believe that properly supporting all
| the various use cases an issue tracker serves without
| turning it into another JIRA is a hard UI design task.
|
| But at the same time, practices like closing or locking
| stale bug reports can be seen as _UI workarounds_. Some
| people feel their boards are cluttered, so they reach for
| the only tools available - the close button, the lock
| button, an autoclosing /autolocking bot. It solves the UI
| issue for them, at the expense of other groups of board
| users.
|
| This is to say: it's ultimately an UI deficiency on the
| part of a common issue trackers. Developers should be
| able to restructure their board as they see fit, but it
| shouldn't impact other users' ability to utilize the data
| stored on it. It would be great if major software forges
| solved this on their end.
|
| Perhaps we need a concept of a "stale" issue/thread
| that's distinct from a "closed" one. A stale issue would
| be one that's not actively being looked at, but is
| nevertheless not resolved. The way it would differ from a
| regular open issue is:
|
| - It doesn't sort itself up when somebody posts a comment
| on it.
|
| - Posting on it doesn't notify people who didn't
| explicitly subscribe to it - all activity on stale issue
| is grouped under a single, inconspicuous indicator, that
| can be easily ignored.
|
| - Stale issues are always sorted to the bottom or kept on
| a separate tab, and are trivial to filter in or out
| during searches. But the tab marker itself stays
| _visible_ , so that people can find out there are such
| issues in the first place.
|
| - Stale issue can be explicitly promoted to active at the
| discretion of the developers (or perhaps by community
| vote).
|
| Hopefully this would reduce the need to aggressively
| close - and especially to _lock_ - older issues.
| Jenk wrote:
| Stalebot (the popular one on GH) has exemptions which are
| configurable - branch, author, label, commenter, and
| probably more. AKA owner/maintainer can do as little as
| drop a label or even just a reply on an issue and it
| won't be pruned.
| feu wrote:
| Closing an issue shouldn't prevent anyone from finding it
| though. At least on GitHub closed issues are still
| visible in the issue tracker.
| innocenat wrote:
| Who search for _closed issues_ when searching if other
| have the same bug?
| NicoJuicy wrote:
| I do. Because perhaps it's fixed in a newer version or
| ...
| TeMPOraL wrote:
| I do, _because_ I realized people close stale issues just
| because (and then there are bots that do it now too). I
| 'm happy I can still do it, and I worry that one day
| someone will have a bright idea to "archive" closed
| issues to where they cannot be easily found.
| kenniskrag wrote:
| I think closed issues shouldn't be a problem on the
| current release. So why search through them?
| TeMPOraL wrote:
| Because - per the pattern of behavior we're discussing in
| this thread - some developers close _old_ issues, whether
| they were actually resolved or not, and it 's becoming a
| common practice, particularly with the appearance of bots
| performing this function automatically.
|
| Also, not everyone is using the most recent release.
| spacechild1 wrote:
| Some issues are not actually bugs but user errors (e.g.
| because they haven't read the manual). Personally I'm not
| sure if it's better to close such issues or keep them
| open with a special label.
| steerablesafe wrote:
| If you can automatically close old bugs then you can
| automatically filter those same bugs, without closing them.
| lloydatkinson wrote:
| 1000% this. The lodash library for Javascript had the
| authoritarian dictatorship extreme version of this for the
| longest time.
|
| _Any_ issue was immediately closed and only _closed_ issues
| would be reopened _if enough people gave said closed issue
| enough thumbs up_ (and "enough" wasn't even defined). And of
| course, this process wasn't explained anywhere except in
| replies to closed issues.
|
| The obvious problem with this was that _no issues were ever
| acted upon ever_ because no one ever looked at closed issues,
| because why would they?
|
| I had created a proposal for a new function to be added that
| was and still is sorely missing. After it was closed and a
| long discussion ensued between many devs, I gave up and a
| year later I simply replied that I retract the proposal due
| to the ridiculous policy of actively being hostile to users.
| The maintainer deleted the whole issue and along with it all
| proof of their hostility and hypocrisy.
|
| It was then that I decided I would boycott lodash and simply
| use better libraries in my projects now like Ramda, which is
| actually OSS. Looks like lodash is now no longer maintained
| and has hundreds of tickets open after the hostile maintainer
| (and it's not hard to guess who from looking at the commit
| counts) appears to have stopped maintaining it.
|
| Funny how that works, closing tickets constantly ensures no
| one will want to help, and then the maintainers feel
| overwhelmed because they are doing it alone.
|
| Basically closing issues is an awful practice that helps no
| one, as you say.
| Qub3d wrote:
| Also known as the "Cascade of Attention Deficit Teenagers"
| (CADT) development model:
|
| https://archive.is/l4svG (jwz link, so archive.is)
| Rompect wrote:
| I never understood how people used lodash. Basically every
| function can be copied and just inserted into ones own
| codebase and you have one less dependency, which is very
| pleasant. And they are all so simple that there will never
| be a problem.
| meetups323 wrote:
| > And they are all so simple that there will never be a
| problem.
|
| "Simple JS can't have unexpected security/performance
| pitfalls".
|
| Hah.
|
| https://www.cvedetails.com/vulnerability-
| list.php?vendor_id=...
| no_wizard wrote:
| _Disclaimer: I am not a security expert! This is my
| layman 's attempt at mentioning a common vulnerability
| too many programs have but not enough knowledge is spread
| about it. It's easy enough to mitigate in most apps but I
| don't think most do._
|
| I know this isn't _directly_ related, however one of the
| vulnerabilities is _prototype pollution_ [0], a
| deceptively simple technique that I think so many apps
| are vulnerable to. It goes like the following:
|
| - Get an application to serialize or take `__proto__`,
| `constructor` or `prototype` as an input so it's a key on
| a JS Object
|
| - Serialize its value to something nasty, like `'{"auth":
| {"name": "user", "password": "pwd"}, "message": { "text":
| "", "__proto__": {"canDelete": true}}}'` [1]
|
| This high jacks the prototype of the object and adding
| those specified properties. If you do things like deep
| merging of objects on data, you are susceptible to this
| without the proper guards in hydration / rehydration. The
| mitigation is simple: don't allow objects to have
| `constructor`, `prototype`, or `__proto__`. You can
| delete them by customizing JSON.parse (by passing a
| reviver [2]) or using something like `mergeWith` to skip
| these keys
|
| A similar vulnerability exists with `constructor` and
| `prototype` as well [3]
|
| [0]: https://portswigger.net/daily-swig/prototype-
| pollution-the-d...
|
| [1]: https://github.com/Kirill89/prototype-pollution-
| explained
|
| [2]: https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
|
| [3]: https://shieldfy.io/security-wiki/prototype-
| pollution/introd...
| unilynx wrote:
| What's the security risk?
|
| A prototype can only be modified by code that is actually
| being run. If you can get someone else's application to
| run code under your control, you've already won.
| goldenkey wrote:
| Don't forget that Lodash was basically JDalton's rip of
| Underscore.js. There used to be a mention of it, since the
| selling point was benchmarks. Now, I don't see any mention
| of Underscore...
| capableweb wrote:
| Not sure I'd call it a "rip", "ripping" for me is
| associated with "ripping media" which is copying
| video/music/data from CDs to local hardware. Lodash is
| more of a re-implementation of a MIT library, not
| something that should be shameful.
|
| As I remember it, Lodash biggest difference was its
| modular approach also, not all about performance. Lodash
| also addressed some inconsistencies in Underscore.js.
| goldenkey wrote:
| Allowed or legal doesn't imply couth. As far as I can
| tell, Lodash no longer mentions Underscore anywhere. This
| seems wrong..as if one wants to look more original than
| one actually is.
|
| I have no qualms with forks or reimplementations (ie.
| Android - Java.) I actively support the paradigm.
|
| But in this case, it's pretty shitty to try to erase all
| evidence of said inspiration. Most forks and
| reimplementations don't do that. They pay homage to their
| origin with at least a shout out.
| capableweb wrote:
| I don't think Lodash ever "credited" Underscore.js for
| it's origin. Lodash used to have a "compat" version that
| promised to work the same as Underscore.js but with
| better performance, but I think that's about it.
|
| After some digging, it seems like the Lodash website
| stopped mentioning Underscore.js around 2015 sometime,
| but even before that, it never had "evidence of said
| inspiration" as claimed by you.
|
| Here are the versions I looked at:
|
| - https://web.archive.org/web/20120826202523/http://lodas
| h.com...
|
| - https://web.archive.org/web/20130502014523/http://lodas
| h.com...
|
| - https://web.archive.org/web/20140517192947/http://lodas
| h.com...
|
| - https://web.archive.org/web/20150513014815/https://loda
| sh.co...
|
| - https://web.archive.org/web/20160803063412/https://loda
| sh.co...
|
| - https://web.archive.org/web/20170830163720/https://loda
| sh.co...
|
| - https://web.archive.org/web/20180703043557/https://loda
| sh.co...
|
| - https://web.archive.org/web/20190803030353/https://loda
| sh.co...
|
| - https://web.archive.org/web/20200615092636/http://lodas
| h.com...
|
| - https://web.archive.org/web/20210314233141/https://loda
| sh.co...
| goldenkey wrote:
| Good digging. The 2012 banner is > A
| drop-in replacement\* for Underscore.js
|
| I'd consider this to be an admission of where the API
| came from.
|
| You are right though, my memory failed me. No mention of
| forking.. Shameless!
| theta_d wrote:
| Rip short for rip off which can mean a clone essentially.
| cowsandmilk wrote:
| Really, lodash was a fork of underscore, not a
| reimplementation. The git history shows it.
|
| https://github.com/lodash/lodash/commits/0.1.0?after=e097
| 1cd...
| capableweb wrote:
| Perfect, even better! Now we can all correct ourselves
| and call it a fork, which sounds much nicer than "rip",
| "ripoff" or "clone".
| goldenkey wrote:
| Most forks mention their origins somewhere in their bio.
| I'd still call it a rip considering no credit is being
| given at all. Why should I need to dig into the Git
| history to find out the creative origin of Lodash?
| capableweb wrote:
| > Most forks mention their origins somewhere in their bio
|
| Ok, does that make forks who don't mention where they
| forked from rips? Huge leap in logic.
|
| > Why should I need to dig into the Git history to find
| out the creative origin of Lodash?
|
| Well, if you're interested in the origin you either look
| for information available in threads like this, where
| other people dig or you dig yourself. Not sure what the
| problem is. Someone published a library under MIT,
| another person forked that library and created a new one,
| also under MIT, and somehow the fork is now a rip? Give
| me a break
| Karunamon wrote:
| The license file reads: _Based on Underscore.js,
| copyright Jeremy Ashkenas, DocumentCloud and
| Investigative Reporters & Editors
| <http://underscorejs.org/>_
|
| If they were giving "no credit at all", they would be in
| violation of the MIT license.
| design-material wrote:
| More accurate is 'stolen code without proper attribution'
| capableweb wrote:
| Hope you don't publish any MIT code and then blame people
| when they fork it. That'd be really against the spirit of
| the MIT license.
| Karunamon wrote:
| https://raw.githubusercontent.com/lodash/lodash/4.17.10-n
| pm/...
|
| > _Based on Underscore.js, copyright Jeremy Ashkenas,
| DocumentCloud and Investigative Reporters & Editors
| <http://underscorejs.org/>_
|
| They've given precisely as much attribution as is
| required.
| dorian-graph wrote:
| > "ripping" for me is associated with "ripping media"
| which is copying video/music/data from CDs to local
| hardware
|
| For many others, the OP's use is common and correct--in a
| lot of areas.
|
| "They ripped me off" is very prevalent in English
| speaking countries too, outside of tech.
| capableweb wrote:
| Yeah, that's my understanding as well, from "ripped me
| off", implying stealing or something negative.
|
| Having the (almost) same API surface as another MIT
| library is hardly a "ripoff" but a re-implementation.
|
| Edit: since new evidence has come forward
| (https://news.ycombinator.com/item?id=27275379) I think
| we can all agree that Lodash is a fork of Underscore.js,
| nothing more and nothing else.
| DonHopkins wrote:
| "Rip-Off Menu" is another term of art for "Tear-Off
| Menu". ;)
|
| Inside Macintosh > Macintosh Human Interface Guidelines >
| Part 2 - The Interface Elements > Chapter 4 - Menus >
| Tear-Off Menus and Palettes
|
| http://mirror.informatimago.com/next/developer.apple.com/
| doc...
|
| http://mirror.informatimago.com/next/developer.apple.com/
| doc...
|
| >A tear-off menu allows users to move a menu around the
| screen like a window. Tear-off menus save desktop space
| because the user can place them on top of a document or
| move them to a convenient position. If you implement a
| tear-off menu rather than a fixed palette in a window,
| you allow the user to have a larger workspace in document
| windows. Users can also choose to leave the menu in the
| menu bar, or tear it off and close it when necessary.
| Tear-off menus give the user more flexibility than fixed
| palettes do.
| hinkley wrote:
| How _is_ underscore these days?
|
| Lodash as an npm module is out of control, file-size
| wise, and I'm not sure I'm really getting anything for
| it, other than once a year having to make sure we don't
| have ten copies of it that can't be deduped (Currently
| it's occupying 29MB of disk space on my production
| machines)
| achempion wrote:
| You could try to look on in from another perspective.
|
| The library is free and worked on by maintainers in a spare
| time from main duties (not talking here about lodash
| specifically).
|
| Maintainers don't own you any support nor obliged to work
| the way you may think they should.
|
| I would say that it's great that we have many tools and
| should give more respect to maintainers which basically
| save you a ton of resources and maximum they ask for is to
| follow the established processes.
| [deleted]
| NetOpWibby wrote:
| You haven't addressed the hostile attitude of the
| maintainer, which was the point.
| a1369209993 wrote:
| The hostile _and deceptive_ attitude of the maintainer.
| If they honestly admitted that they didn 't give a crap
| about bug reports, or even just didn't bother setting up
| any system for recieving them, that would _disappointing_
| , but achempion's comment would cover the situation
| nicely. The problem (assuming the previously stated
| _facts_ are accurate) is they actively set up a system to
| solicit and recieve bug reports, and then systematically
| sabotaged and neglected that system when people tried to
| actually report bugs.
| hinkley wrote:
| I feel like we could have the same conversation about the
| Docker folks and so this feels more like a popularity
| contest than an objective conversation.
| fn1 wrote:
| This came up in the javascript-world.
| zaphirplane wrote:
| I disagree for bugs in volunteer open source because it
| requires someone to triage it and recreate the bug cross
| versions. Vlc version x.y.z on Ubuntu version a.b.c cross
| versions of vlc and Ubuntu is it still valid
|
| The process of closing it means pushes that work back on the
| users obviously this requires the coders to keep an eye on
| the bugs and assess their importance
|
| Having 8000 bugs cross 10 years with ancient versions helps
| no one
|
| FWIW In this case it's a feature request
| arghwhat wrote:
| It depends solely on the definition of "stale".
|
| An issue where the reporter is unreachable and developers do
| not have local reproduction should absolutely be closed as it
| serves no function other than generating noise in the issue
| tracker.
|
| Open issues is a liability to overview and planning, and
| having bad open issues is therefore directly harmful to
| maintainers, reporters and users.
|
| Closing a bad but ultimately real issue will just make way
| for a possibly _good_ report to take it 's place (i.e. a new
| reporter rather an old unresponsive one) so it only provides
| benefit.
| xattt wrote:
| It helps people gain a sense of productivity when a lot of
| yak shaving place.
| johnchristopher wrote:
| As a bug reporter I take it very personally when it happens
| to me.
|
| When I try to debug a problem and I see it has already been
| reported and closed due to inactivity (that is :not fixed.
| Not tagged won't fix) I give up, I won't fight the machine.
| bassdropvroom wrote:
| I disagree. It entirely depends on the behaviour.
|
| I've lost count of the number of tickets that have been
| raised that has no information, or is not reproducible, or
| something else. When I then ask for more information, or
| something else, they never reply. I've no incentive to keep
| such tickets open.
|
| So I set up stale bot and auto-close the tickets. Individuals
| can come and re-open if it happens to them, or more
| information is added.
|
| Now I do agree, if it is a genuine issue, then it shouldn't
| be closed until it is sorted out it. So you can set up stale
| bot to ignore labelled or something. So that's how I've set
| up all of my repos. For me this has taken off a huge burden.
|
| I don't agree with locking threads after they've closed
| though. There is very little reason to do so.
| kubajastrz wrote:
| One way that I found out recently in the vite github
| repository [0], is to use github actions cron job to
| automatically close issues with certain labels, like "needs
| reproduction".
|
| This way maintainers need to at least explicitly set the
| label before the issue is closed automatically, and not the
| other way around.
|
| [0]: https://github.com/vitejs/vite/blob/b6d12f71c1dbd5562f
| 25bc2c...
| hinkley wrote:
| I think the problem is that the bot is the wrong solution
| to the problem.
|
| It's like when I was clearing out my inbox of spam - about
| 10% of the garbage was legitimate spam, the rest was self-
| inflicted spam - ads for places I frequent, and mailing
| lists that I kept thinking I would read 'some day'.
|
| What I needed was a way to group all of the suspicious
| messages so that I could machine gun my way through them
| spending less than a couple of seconds each. First hour got
| a lot of dead messages quickly, slowing down over time and
| totaling about 4k messages by hour four (most of that spent
| in front of a TV, which let me finish but also made it take
| longer - if you ignore the divide by zero error).
|
| What you need is a way to tag suspicious issues so that you
| can go through and veto the 20 that are legit, and delete
| the rest. But that may require some feature requests to
| GitHub, and a different bot.
| eptcyka wrote:
| This is different from closing legitimate bugs/issues that
| are well described and testable, just not fixed.
| bassdropvroom wrote:
| That's right. It's all use-case based. Indiscriminately
| closing issues automatically is definitely wrong.
| Automatically closing issues that cannot be reproduced or
| have other issues is a perfect use-case for stale bot.
| eptcyka wrote:
| Show me a bot that can tell the difference between a
| testable and well described bug and one that's affecting
| lots of users but has bad descriptions.
| bassdropvroom wrote:
| Using GitHub's stale bot you can set it to ignore
| labelled issues, and so it's up to maintainer to label
| things correctly. Once the maintainer does so, stale bot
| won't touch it.
| eptcyka wrote:
| How is that different from someone closing the issue
| manually?
| mook wrote:
| I believe that's backwards -- it requires active effort
| from the maintainer (who may be on vacation) to prevent
| closing, when the ball is in the maintainer's court (to
| check if it's a reasonable ticket). The process described
| elsewhere in this subthread, where the maintainer has put
| a label on the issue before it can be auto-closed, is
| better (since the next action is on the reporter); that
| must only happen if the reporter hadn't responded,
| though.
| frereubu wrote:
| In an ideal world I'd agree with you, but if you or your team
| don't have the time to fix every bug - some of which will not
| be critical - then having a mass of open issues pile up often
| leads to people being overwhelmed and fixing even fewer.
| Also, over time, some issues are superceded by changes
| elsewhere so they become moot anyway.
| bayindirh wrote:
| Why not move them to a low visibility category like a back-
| burner?
|
| Some long standing problems get progressively easier to fix
| when the blockers around a bigger problem gets conquered
| slowly due to requirements.
| asoneth wrote:
| I agree that auto-closing bugs is unfortunate, but I
| understand the motivation.
|
| I've worked on legacy codebases with thousands of unresolved
| issues old enough to drink. Those issues were probably
| triaged and reproduced by the people who hired the people who
| hired me and had been lovingly transferred during multiple
| bug tracker migrations, but they never achieved high enough
| priority to warrant development attention. And certainly no
| one on the current team had any interest (or time) to dig up
| and attempt to reproduce issues that no human has touched in
| a decade. Just reading through all the old issues would
| require a larger team than the product revenue could sustain,
| let alone reproducing and resolving them.
|
| Having said that, there was no harm in keeping old issues
| "open" because everyone on the team used metadata to filter
| old issues out of their views so they were effectively
| "closed" in that no one ever saw them unless they
| deliberately went looking and they stopped being included in
| summary reports. No idea whether people would consider that
| better or worse than explicitly marking them as "Closed".
| ryandrake wrote:
| Not sure if relevant to open source bug tracking, but I've
| worked in more than one company whose "old bug" policy
| boiled down to: If after we found this bug, we chose to
| ship an update that did not include a fix, then the bug is
| not important enough to ever fix and should be closed as
| "Won't Fix". In other words, customers have lived with this
| bug for at least two release cycles and the world didn't
| come to an end, so don't prioritize it. I don't agree with
| this policy but I think it's a pretty common mentality in
| the commercial software world.
|
| EDIT: Additionally, I've never worked anywhere where the
| capacity/willingness to fix bugs exceeded the incoming
| rate. So net bug count minus fixes would always grow
| forever unless you regularly purged unfixed bugs. This
| seems almost universally true in software.
| Arathorn wrote:
| +1E100. On a busy project it's disasterous if long-lived
| chronic bugs which are serious enough to be tracked in the
| first place, but have never quite made it to the top of the
| todo list, randomly got closed for no good reason. This issue
| is a classic case in point. We have too many similar ones on
| Matrix (but which we've been slowly working through over the
| years).
| rvz wrote:
| > I've said it before and will keep on saying it: GitHub's
| stale bot should be removed with prejudice.
|
| Imagine if the Linux kernel or even Chromium had stale bots
| closing reported vulnerabilities everywhere. It's like they
| are burying bugs waiting to be exploited by drive-by security
| researchers.
| handrous wrote:
| Android, notoriously, does this. When (not if) you hit an
| Android bug while developing an app, more than likely
| you'll find it closed as stale. Luckily they don't usually
| block comments, so you'll get to see confirmation from
| within the last few weeks that you're not crazy and this
| bug is still present, and maybe some up-to-date workarounds
| if you're lucky.
| dawnerd wrote:
| Worse is when they prevent you from reopening or if you
| comment after it's closed you get a rude response to open a
| new ticket.
| heinrichhartman wrote:
| I can get behind closing stale issues, to a certain degree,
| but this practice sound straight-out stupid: Why would you
| discard the context of a previews discussion?
| TeMPOraL wrote:
| At the risk of spinning of a tangent flamewar: this ties
| into a wider issue that boggles my mind to this day - the
| concept of "necroposting" as something negative. People
| will commonly want to eat you alive if you post a new
| reply under a stale discussion thread, but that reaction
| feels really dumb. The old context is _useful_.
| travisjungroth wrote:
| Agree for intelligent discourse about a slow-moving
| topic. Disagree for conversations about personal opinions
| (most of forums), especially ones with time context. When
| you post on a three year old thread, everyone else has
| left the room. That's fine if you want to share how you
| finally got this old sound card working on a specific OS,
| lame if there was a lively discussion about working at
| Lyft versus Uber.
| lucideer wrote:
| Firstly there's a 3rd type: someone asks for help and you
| post a suggested solution 3 years later. Extremely useful
| for all the lurkers who also had the same question and
| are reading looking for possible solutions.
|
| But secondly, even your own counterexample I don't think
| checks out. If I'm browsing your forum & interested in
| perspectives on working at Lyft v Uber, I absolutely want
| to read a recent update and contrast that with what
| people thought 3 yrs ago v now.
|
| Tbh, the "I got my sound card working" post seems least
| appropriate of them all (but still ok to do imo,
| necroposts are good)
| travisjungroth wrote:
| My sound card example was supposed to be like your 3rd
| type, so we agree there.
|
| Old and current experiences are definitely both valuable.
| Just start a new thread. It's too easy for other members
| to miss the dates when it comes back to the top. Then
| they're reading and responding to old posts from absent
| people like they're here and now.
| alpaca128 wrote:
| For me the reason I see it mostly as something negative
| is because most necroposts are pointless. They're often
| only written because the author forgot to check the date
| and thus didn't realise their comment won't contribute
| anything useful. Like when a user tells others in a 7
| years old, obsolete thread they're wrong because shiny
| new solution XYZ exists.
| lucideer wrote:
| but that's just a reasonable response to a _specific type
| of comment_ , not a general defense of banning necroposts
| outright.
|
| The reason the term exists is because it's a blanket rule
| based on the age of the reply, not based on the intent or
| context.
| chc wrote:
| The blanket rule is because even "good" necroposts tend
| to encourage bad ones. If I'm on an active forum and I
| revive some ancient discussion with a useful comment,
| lots of people will click on the thread and try to argue
| with the old posts.
|
| The generally recommended alternative is to make a new
| thread and simply link to the old one so you don't
| confuse people.
| TeMPOraL wrote:
| > _the author forgot to check the date and thus didn 't
| realise their comment won't contribute anything useful_
|
| I have a different view of those in most cases -
| particularly on large, or publicly accessible, boards.
| That comment may not contribute anything useful for the
| people previously involved, but it may very well be
| useful for _everyone else_ - such as any person that
| finds the thread through a search engine.
|
| > _Like when a user tells others in a 7 years old,
| obsolete thread they 're wrong because shiny new solution
| XYZ exists._
|
| That's a specific case about one-upping someone much
| later, but a more generalized case - posting modern
| solution under unresolved problem thread - is very
| valuable for people who find the thread looking for a
| solution. Conversely, blanket ban on "necroposting"
| discourages accumulation of knowledge on tough problems.
|
| See also: https://xkcd.com/979/
| smichel17 wrote:
| I agree that a blanket ban on necro-posting has the
| negative consequences you mention. It is commonly
| discouraged as a _heuristic_ , because necro-posts often
| have a high time cost to those who were previously
| involved. First, because by that time they've forgotten
| the context, and since the new post often does not
| summarize the entire previous conversation, it forces
| someone who wants to make sense of it to go back and re-
| read it to understand that context. In contrast, a new
| issue is more likely to stand on its own and be easier to
| process. It can still _link_ to the old issue in order to
| keep the chain intact. And second, because the new
| commenter is often _wrong_ that their bug is the same, or
| has missed some of the context and is just adding
| duplicate information. Note that both of these apply more
| to long threads.
|
| I think this suggests two things:
|
| 1. There is an opportunity for better tooling. I'm
| thinking something like those annoying infinite scroll
| news/blog sites, where you reach the end of the article
| and it dynamically sticks another one on the page below
| (& updates the url). Imagine that but with any bug that's
| been marked as a duplicate (which the bug reporter should
| be able to do). Now you get the best of both worlds -- a
| way to view the new post with or without context.
|
| 2. Necro-ing would be less problematic if bug tracking
| were less centralized. More long, support-type bugs
| between distributors and users, where is preferable to
| log a new issue than necro an old one; more short
| summaries of confirmed bugs submitted by maintainers to
| the upstream repo. GitLab's separation of issues and
| epics is a good idea here, although their implementation
| is awkward at best.
| TeMPOraL wrote:
| > _And second, because the new commenter is often wrong
| that their bug is the same, or has missed some of the
| context and is just adding duplicate information. Note
| that both of these apply more to long threads._
|
| That's a good point I haven't considered. Yeah, the
| consequence of mistakenly starting a new topic under an
| unrelated old thread is that the new discussion is now
| miscategorized and harder to find.
|
| > _It can still link to the old issue in order to keep
| the chain intact._
|
| Yes, that would be great. If one could pull off an UI
| that nudged people to correctly link back to older
| threads, so that such links were typical, I think it
| would mostly solve the necropost problem - the etiquette
| could be changed to "don't necropost; if starting a new
| thread on a topic that was discussed in the past, ensure
| your post links back to those old discussions".
|
| (I think I saw a few boards automatically generating a
| box with "related topics", but IIRC, their method of
| finding related topics yielded lots of false positives.
| If improved, this could work too, though I would still
| prefer explicit links that _don 't change over time_.)
|
| > _I 'm thinking something like those annoying infinite
| scroll news/blog sites, where you reach the end of the
| article and it dynamically sticks another one on the page
| below (& updates the url)._
|
| I personally don't want that. I hate this UI pattern. In
| particular:
|
| - As implemented on social media platforms, it makes it
| nearly impossible to find your way back to something you
| saw a minute ago but scrolled past.
|
| - As implemented on news sites, auto-appended articles
| are usually not relevant to the one you just finished.
|
| - The URL substitution is particularly annoying -
| usually, the time I care about the URL is when I
| read/skim the article to the end, and then decide to
| share or bookmark it. At that point, the URL will already
| be changed to point to a different article, and it's easy
| to miss. And the way these feeds are implemented, if you
| follow the link to a follow-up article and scroll up, you
| won't get back the article you actually wanted.
| detaro wrote:
| _If_ the old context is useful, sure. but it often isn
| 't, and that's what causes people to dislike
| necroposting. But without a specific policy/instance in
| mind discussing this is a bit moot, since everyone has a
| different level of reasonableness in mind.
| wott wrote:
| > boggles my mind to this day - the concept of
| "necroposting" as something negative.
|
| I never understood it either. I mean, as a religion.
|
| What is even sillier, is that as far as web forums are
| concerned, you have 50% of them which will go mad if you
| "necropost", and the other 50% which will go mad if you
| open a new thread when there is already an existing
| thread on the same topic (even buried), because these
| have the exact opposite written or unwritten rule. The
| latter ones love their 800 pages long topics; the former
| ones forbid you to follow up with a discussion even when
| it is the exact same topic, if the discussion stopped for
| a while.
| TeMPOraL wrote:
| You know what beats that still? I've been using a few
| boards where people believed in _both these things at the
| same time_. So when a topic stalled, it was nigh-
| impossible to resume it later.
| zerocrates wrote:
| Getting redirected to post on a locked thread where
| that's not allowed... I propose to call this the
| Catch-302.
| wott wrote:
| Ah! :)
|
| I've seen something a bit like that: moderators who would
| come down hard on people who ask a question, both in an
| old thread or a new one (because the first time they were
| told not to create new threads or not to necropost so
| they tried again, following the advice, in the opposite
| manner), by telling them "why can't you search the
| fucking forum 2 minutes before digging an old thread /
| creating a new thread, stupid; this has been answered
| multiple times: here, here and here; topic locked", and
| of course none of the links he gives does answer the
| specific problem the posters had and clearly specified,
| because the mod didn't spend the said 2 minutes reading
| the posters' questions and just stupidly copied the first
| search results in the rush he had to punish the
| intruders. So, when you hit the same problems as the
| posters, you are out of luck, because their questions
| were not answered before, and they will never be.
| kergonath wrote:
| I have seen this unfortunate behaviour in mailing lists
| for some Open Source software as well. Gatekeepers with
| anger issues and too much time on their hand (but not
| enough to actually answer the question). Sometimes I wish
| these people realised how hostile they are and
| unwelcoming to new users and potential contributors, but
| maybe that's the point.
|
| The result is ~10 relevant hits when you Google an error
| message with not a single useful solution.
| twic wrote:
| There's at least one forum out there where necroposting
| is actually valued by the culture. It's considered cool
| and fun to make a relevant post on a thread that was last
| updated five years ago. I love that.
| smeyer wrote:
| Which forum?
| strogonoff wrote:
| I don't think "necroposting" is something inherently
| bad[0], but specifically insisting (or expecting) that
| open-source project maintainer remembers a 100-screen
| thread every time anyone wants to bring it up is IMO ill-
| mannered.
|
| A random person online invests an afternoon to read
| through a years old issue thread and decides to comment,
| expecting the maintainer to reply. Meanwhile, maintainer
| has dozens of such issues, and dozens of frustrated users
| bringing up each of them every week. Asking the submitter
| to respect a previously made maintainer's decision, file
| a new issue and invest _their own time_ to concisely
| summarize the status quo seems only fair.
|
| In other words, diverting discussion to a new thread is a
| chance to compress old context into a short summary, like
| you would squash a Git history--except in this case the
| old closed issue thread is fully linkable and isn't going
| anywhere.
|
| [0] That said, it depends on maintainer's personality. I
| can see how some could feel losing control and
| demoralised by ever-evolving difficult-to-track
| discussions on previously closed issues.
| lucideer wrote:
| You're right that this behaviour is bad and I know that
| what you describe happens but it seems like a strawman
| argument in the context of this discussion.
|
| What you describe is about the community respecting foss
| maintainers; closing tickets is not going to solve this
| problem.
| strogonoff wrote:
| I was responding to the point about comments piling on a
| closed issue. It is not bad by default, but still there
| can be valid reasons for maintainers to discourage it.
|
| Whether an issue should be closed or should be allowed to
| be re-opened by the public is not even up to debate as
| far as I'm concerned, this is up to maintainer's policy.
| jlarcombe wrote:
| Amen. About once a year I spend an entire day reopening bugs
| in the Qt bug tracker while somewhere in Finland someone is
| sitting there closing them, like a sort of really annoying
| game. The process consists of (a) downloading the minimal
| test app attached to the bug, (b) making a trivial change to
| get it building with the latest Qt, and (c) reopening the bug
| with the remark "this still happens in Qt X.latest".
| Unfortunately I can't quite do this as fast as they can close
| them...
| MrOxiMoron wrote:
| not searching closed issues is always bad, things that are
| fixed in a newer version or after long discussion are closed
| as won't fix won't be found either
| agilob wrote:
| This is even worse, competitive projects are compared to each
| other based on number of OPEN issues, making the project that
| ignores "stale bugs" look better than project that keeps bug
| until actually solved. I've seen this thinking twice in
| action, a teach leads decided to use react native over
| flutter, because RN had fewer issues
| mumblemumble wrote:
| In general I don't disagree, but I'd moderate the position
| with context.
|
| For projects that have some sort of product manager who is
| personally in charge of managing and perhaps de-duplicating
| the tickets, I'd leave the choice up to them. Some like
| having only one ticket that captures all discussion about an
| issue. Some don't care, and aren't so worried about losing
| track of comments from several years ago. That feels to me
| like a work style issue, and I don't need to tell them how to
| do their job.
|
| Or, for projects that are working with an issue tracking
| system that makes it really difficult to juggle large numbers
| of open tickets, I also see it as potentially valuable. It's
| a trade-off. Yes, you get a little extra chaos from broken
| discussion around perennial issues. But, if you simply cannot
| effectively manage and prioritize more than, say, a hundred
| open tickets, then that might be the lesser of two evils.
| fuzzy2 wrote:
| Previous discussion on pretty much the same topic:
| https://news.ycombinator.com/item?id=26256459
| hardwaresofton wrote:
| > The common practice now is to "close stale issues", which was
| discussed recently, though I can't find the thread.
|
| This is bad and borderline dishonest practice, and it's
| surprising that it's allowed to be widespread. I wrote an edgy
| post about it which didn't go far on HN but it's a sentiment I
| don't see repeated much (without the edge of course).
|
| Filed issues say something about your product or it's
| documentation/UX. Bots that autoclose muddy that signal.
| CGamesPlay wrote:
| Au contraire, I think they amplify that signal! It sends a
| pretty clear message to people who file these annoying issues
| as well as acts as a deterrent to would-be pests who search
| for an existing issue before filing.
| hardwaresofton wrote:
| I dunno, if you want to do that it would actually be better
| to just send that clear message in a more direct manner --
| GitHub just doesn't have good tools around this yet. Until
| better tooling gets here, maybe it makes sense to just very
| quickly ban pests, and make it clear that pests won't be
| tolerated?
|
| Also I want to point out that I'm totally fine with quickly
| closing tickets with no reproduction details or without
| enough information. Bad tickets should get closed if
| they're bad, especially if there's a template in place that
| the person has ignored. I would say that if 10 tickets from
| different people are getting filed from a specific area it
| may be worth looking at even if all the tickets are badly
| specified. In general a closed ticket with an explanation
| is so much more valuable over time than the alternative.
| a1369209993 wrote:
| > It sends a pretty clear message
|
| No, it doesn't. If you want send that message _clearly_ ,
| you should state in your readme: "We don't give a fuck
| about bug reports, especially if they're valid and
| relevant.".
| aasasd wrote:
| > _Filed issues say something about your product_
|
| Yes, it says that the product is popular enough that hundreds
| of people feel the need to post feature requests with notes
| like "how is this not fixed yet, it should be five minutes of
| work, it's a deal-breaker issue for me, I'm migrating to
| Chrome if this is not fixed!!!"
| whywhywhywhy wrote:
| Compare browser market shares when this bug was posted and
| now, they did leave.
| hardwaresofton wrote:
| Ban those people then -- no one is entitled to have their
| voice heard in the comments of your issues, or even to file
| issues on your project.
|
| Also, this comment wasn't about Firefox specifically! Just
| about projects that do this in general.
| rorykoehler wrote:
| It just creates an incentive to game the system. Stale issues
| get closed after 90 days? Run a script that asks for an update
| on the issue every 89 days...
| kome wrote:
| when will be the turn for
| https://bugzilla.mozilla.org/show_bug.cgi?id=734643 ? 9 years
| already.
|
| I wish I could donate just to fix this bug for everybody.
| megamix wrote:
| Some things are not meant to be fixed hehe. I love old bugs!
| mariusmarais wrote:
| Hope it wasn't P1 for the full 21 years.
|
| Edit: Bumped from P3 -> P1 3 months ago :)
| xfz wrote:
| I just hope there's no regression. :)
| was_a_dev wrote:
| A 21 year old bug. At that point the developer creating the fix
| could have been younger than the open issue itself
| jaza wrote:
| And the bug can legally drink alcohol (in the silly still-
| over-21 US).
| DonHopkins wrote:
| This bug is old enough to run for president:
|
| https://www.youtube.com/watch?v=u729hGPyi6M&ab_channel=Silve.
| ..
| singhkays wrote:
| One of the problems I've found with native context/drop down
| menus is that when you're sharing a specific window on Zoom, the
| context menus don't show up on the video.
|
| You have to share your entire screen to show someone all the
| available options in the context/drop-down menu.
| formerly_proven wrote:
| That's because context menus are a separate top-level window
| with their own event loop on all windowing systems (even macOS,
| I think). The drop-down you get on a combo-box is a similar
| deal, at least on Windows and X11.
| pwdisswordfish8 wrote:
| The cynic in me thinks this just happened because of a code
| rewrite they wanted to do anyway for reasons unrelated to this
| bug report. It's just a coincidence that the rewrite allowed them
| to close it. (The initial report mentioned XUL, which if I
| understand correctly, isn't even used in Firefox any more.) This
| is hardly some kind of a commendable instance of listening to
| your users.
|
| I mean, compare it to this bug report:
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=309807
|
| First the response was 'just use an extension'. I did that
| happily, until the extension API was neutered, making the
| extension non-functional. When people brought that up, Mozilla
| closed comments on the bug report. Now it is closed as WONTFIX
| with this laughable excuse:
|
| > Extension APIs (which I know aren't yet available) would be the
| solution for implementing this if there is enough demand.
|
| Meanwhile, Chromium had this from day one. It works a bit
| differently now, but it's still there, I just checked. Doable?
| Perfectly doable.
| abdusco wrote:
| One thing that bugs me is that on macOS access keys[0] are not
| underlined. This means I can't pick an action with the keyboard
| and have to use the trackpad. Anyone know how I can enable it /
| if that's even possible?
|
| As a recent Mac user, I don't know if this is a mac thing, but I
| hate not being able to use the keyboard to navigate around the
| UI. Although the trackpad is nice, it can't beat the precision of
| the keyboard. I can't focus the menu bar, trigger a context menu
| with the keyboard, tab around panels and buttons. It's an
| accessibility nightmare.
|
| [0]: https://docs.microsoft.com/en-
| us/windows/win32/uxguide/image...
| saagarjha wrote:
| [?]? is a good way to get to the menu bar on macOS.
| mmphosis wrote:
| One thing that bugs me is that on Windows access keys[0] are
| underlined. This means I accidentally hit the ALt key all the
| time and some unintended action happens. Anyone know how I can
| disable it / if that's even possible?
|
| As a recent Windows user, I don't know if this is a Windows
| thing, but I hate inconsistent keyboard navigation in the
| various UIs. Although the keyboard is nice, it can't beat the
| precision of the mouse. The unwanted focus on menu bars, the
| unwanted triggering of menus with the keyboard, and too many
| modes: tabs and panels and dialog boxes. It's an accessibility
| nightmare.
|
| [0]: https://developer.apple.com/design/human-interface-
| guideline...
| kristiandupont wrote:
| I honestly don't know if you are joking or not. MacOS is
| superior to Windows in many ways but this is clearly not
| one..
| WhyNotHugo wrote:
| I find using macOS with a keyboard near impossible.
|
| One of the issues is how hard it is to discover what the right
| keybindings are.
|
| Second issue is that all the keymappings are different to
| Windows/Linux/BSD/AnythingElse.
|
| Like, in the setup wizard when you open a new mac, hitting
| "return" won't move you to the next step, you have to hit tab,
| and then space. However, near the end of the setup process,
| there's a screen where tab doesn't work, and you actually DO
| have to use return.
|
| I'd had carpal tunnel (and it's kind of a chronic thing), so
| using a touchpad to point-and-click is literally painful for
| me. A mouse is okay, but it seems to be impossible to connect
| bluetooth devices on macOS without using the touchpad.
| acdha wrote:
| > One of the issues is how hard it is to discover what the
| right keybindings are.
|
| In addition the display in the menus, you can use the
| keyboard settings' shortcuts section to see the global
| keybindings and add new ones either globally or within a
| particular app.
|
| There's also a pretty comprehensive version here:
|
| https://support.apple.com/en-us/HT201236
|
| > Second issue is that all the keymappings are different to
| Windows/Linux/BSD/AnythingElse.
|
| There's a bit of early GUI history which explains most of
| this - MacOS was the earliest mainstream GUI and they had
| guidelines pretty early on which most Mac applications use. A
| decade or so later IBM decided they needed to create their
| own standard (Common User Access) which they pushed to get
| implemented on OS/2, Windows, and other operating systems.
|
| Mac users continued to want what they were familiar with, and
| applications which were business-focused in the late 80s-90s
| got CUA, and a whole lot of other software got some
| agglomeration of whatever the developers were familiar with
| and/or the toolkit they were using provided by default.
|
| > I'd had carpal tunnel (and it's kind of a chronic thing),
| so using a touchpad to point-and-click is literally painful
| for me. A mouse is okay, but it seems to be impossible to
| connect bluetooth devices on macOS without using the
| touchpad.
|
| Two ways:
|
| 1. If it's an Apple mouse with a lightning port, plug it in
| once with the cable.
|
| 2. It sounds like you might not have activated the
| accessibility setting which toggles tab navigation from only
| navigating between text fields to all controls. Use
| Control-F7 to toggle that and then: 1. Open
| settings - you can use Spotlight via Command-Space or Option
| + either the sound or display adjustment keys to open
| Settings without using a pointing device 2. Either
| navigate the icons or use search to select Bluetooth
| 3. Hit tab, the default focus ring will be on the "Turn
| Bluetooth Off" button if full control navigation mode is
| enabled. 4. Hit tab, focus will now be on the
| devices list 5. If your mouse is pairable, it'll
| show up with a connect button. Use the arrow keys to select
| that line and hit enter.
| userbinator wrote:
| The most perplexing one that stands out in recent memory is
| in the file explorer, where pressing Enter doesn't open the
| selected item, but _begins a rename operation._
| CGamesPlay wrote:
| Not exactly what you asked for but a pretty great tip is to use
| Command-Shift-/ to select the search field in the Help menu,
| and using it as an ad-hoc command palette for all MacOS apps.
| danrodney wrote:
| On Windows I find it hard to remember random letters for
| accessing menu items. On macOS when a menu is active I can
| start typing the name of an item to go to it, which is easier
| for me because I remember names better than random letters. For
| frequent commands I learn the keystrokes.
| dom111 wrote:
| I might be misremembering but isn't there a key combo ([Fn] +
| [Ctrl] + [F7] or something?) that enabled control selection and
| shows the underlines. I haven't used Mac OS for a while so I
| might be wrong!
|
| Edit: I'm impressed I even remembered that!
| https://support.apple.com/en-gb/HT204434#fullkeyboard
| wffurr wrote:
| I always flip that setting on Macs. The default just seems
| wrong to me.
| oneeyedpigeon wrote:
| Whilst that _is_ the keyboard shortcut for that setting, it
| doesn 't appear to underline access keys.
| dom111 wrote:
| Ahh, I thought it did both, but that must be
| misremembering. A quick search indeed confirms there
| doesn't appear to be a way to do it... Apologies!
| sitharus wrote:
| There is no Mac equivalent to this Windows feature.
|
| You can set up a shortcut to move keyboard focus to the menu
| bar in Keyboard preferences under Shortcuts (in fact you can
| remap any application's keyboard shortcuts there). That's also
| where you can enable keyboard navigation between controls.
| knolan wrote:
| Its control F2
|
| https://support.apple.com/en-us/HT204434
| gholap wrote:
| 1. Disable native context menu (macOS native menus will never
| support access keys)[1]
|
| 2. Go to `about:config` and set `ui.key.menuAccessKey` to a
| custom value (I have it at 17)[2]
|
| [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1711299
|
| [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1711299#c5
| sbahr001 wrote:
| That is a very long bug, 21 years in the making lol
| beltsazar wrote:
| And it breaks my workflow..
|
| When I read a webpage, I often select some words (technical
| terms, movie names, etc), right-click, and press "S" in the
| keyboard for quickly googling the words. I tried it in Firefox
| Developer Edition (equivalent to Firefox Beta) which already has
| native context menus, and it didn't work.
|
| Can't believe this happens to me: https://xkcd.com/1172/
| thinkbud wrote:
| I am in the same boat. There is an about:config flag to revert
| the behavior and use old menus. I am not sure whether the new
| mac-native context menus even have a notion of access keys, so
| I am not hopeful for a fix.
| satysin wrote:
| Wow finally! I have to admit while I love Firefox using it on
| macOS just _feels_ crappy as it is so out of place. I am a huge
| user of the macOS "Look Up" content menu feature and it being
| missing in Firefox always frustrates me.
|
| As silly as it sounds this might just be enough to get me to use
| Firefox as my main browser on macOS. I have played around with
| Nightly recently and love the new UI design. Can't wait for this
| to hit release.
| Kwpolska wrote:
| The trackpad/mouse gestures for Look Up (eg. force pressing the
| trackpad) work in Firefox.
| richardwhiuk wrote:
| Look Up still isn't in the context menu -
| https://bugzilla.mozilla.org/show_bug.cgi?id=1116391
| satysin wrote:
| Indeed I just tried out Nightly and am disappointed it is
| missing. I have given them a little nudge so hopefully they
| add Look Up to the context menu before this hits stable.
| jhatax wrote:
| I know this doesn't get you 100% of the way there, but
| pressing Cmd+Ctrl+D while hovering over a word brings up
| the "Lookup" window in Firefox 88 (similar to Safari).
| neurostimulant wrote:
| Does this still has the bug where Lookup can only look up
| a single word even when multiple words are
| selected/highlighted?
| satysin wrote:
| I just tested this in Firefox and it works on the
| highlight which is inconsistent with how it works
| elsewhere. Usually it selects the word under the cursor
| not the selection. Perhaps Firefox is doing something to
| change the default behaviour?
| scoopr wrote:
| I had taken the habit to use cmd-ctrl-d while hovering over
| words (in any app really)
| kilroy123 wrote:
| It's very sluggish on a Mac. Even on my shiny new M1 is feels
| sluggish. Safari is _way_ snappier.
| beckler wrote:
| I actually experienced the opposite on my M1. Safari locks up
| all. the. time. but it happens more often when I open a new
| tab. I run into a ton of compatibility issues, and I hate
| that you can only install plugins via the App Store.
|
| I really wanted to like safari since it's the most power
| efficient, and when I got my M1 I went all-in on it, but I
| went back to Firefox after three months.
| tobiasu wrote:
| Related: Can anyone share the google search to find instructions
| how to get started with firefox development?
|
| Have they removed it all? I can find old stuff in the archived
| github repo, but that's about it. What's the official entry
| point?
| philshem wrote:
| for developers: https://firefox-source-docs.mozilla.org/
|
| all categories: https://www.mozilla.org/en-US/contribute/
|
| unsure how you can help? https://whatcanidoformozilla.org
| tobiasu wrote:
| Thank you, it's a shame the first link doesn't show up on
| google.
|
| I've found the contribute page, but that leads straight to
| https://github.com/mdn/archived-
| content/tree/main/files/en-u...
| [deleted]
| fen4o wrote:
| Better late than never
| larrysalibra wrote:
| Now if only they'd use the macOS native print dialog like every
| other app. What ever possessed them to roll their own print
| dialog?
| pseudalopex wrote:
| Turn off print.tab_modal.enabled in about:config.
| michaelt wrote:
| They want to show a full-sized print preview, which isn't
| possible on Linux or Windows (I don't know about OS X)
|
| A preview is important as web designers seldom pay much
| attention to print stylesheets; the user probably doesn't want
| to print five pages of navigation menus, or print a black
| background with white text.
| nfoz wrote:
| Thank you, that explanation makes sense.
|
| IMO you should get a preview (with options for changing the
| rendering), and you can go from that to the system dialog.
| Instead of combining them.
| Semaphor wrote:
| Probably because the Windows system dialog is horrible ;)
| kevingadd wrote:
| Yeah, given the number of people who run Firefox on Windows,
| you absolutely need to have a custom print dialog for them.
| Maybe it should default to the system one on OS X, but you
| gotta have that custom one.
| Saint_Genet wrote:
| Probably some wish to be consistent for all firefoxes across
| all platforms. It's pretty common for x-platform software, and
| I think a big mistake. Most people don't move across platforms
| that often and those that do already encounter so many other
| differences a print dialog being recognizable won't make much
| change.
| WhyNotHugo wrote:
| I agree completely on how stupid this is.
|
| A person is a "Windows user", and prints on lots of
| applications on Windows, and expects a consistent experience
| across all applications.
|
| Same applies for Linux users and Mac users.
|
| A person is not a "Firefox user", who prints of Firefox on
| Windows/Linux/Mac. The few people who _do_ fit this unique
| profile, are very much used to seeing very different dialogs
| on all three platforms.
|
| Also, printing in 2021? I get that people still print, but it
| seems equivalent to improving the Fax dialog in 2006.
| kayodelycaon wrote:
| The macOS print dialog has a number of pdf options I use
| frequently.
| handrous wrote:
| > Also, printing in 2021? I get that people still print,
| but it seems equivalent to improving the Fax dialog in
| 2006.
|
| Free coloring pages (like: outlines of characters or
| whatever, you can easily find these with image searches)
| for your kids.
|
| Worksheets for homeschooling or school supplementation, or
| if you're a teacher.
|
| DMing RPGs if you want more than one screen of stuff
| visible at a time, or are trying to avoid screens at the
| table. I find, especially, printing relevant monsters or
| character sheets for likely combat encounters in a session
| to be _super_ useful--saves you flipping back and forth
| between a bunch of things on a screen or doing the work of
| condensing stats, you can underline and notate one or two
| spells on the sheet so you 're not searching at the table
| for "what would this magic-wielding creature probably cast
| first in combat with this party?", for a repeat-encounter
| big nemesis that the party comes to hate you can let the
| party rip up the sheet when they finally dispense with
| them, that sort of thing.
|
| Most of the RPG stuff also applies to serious study or
| working-with-references. Screens still aren't a replacement
| for 20 sheets of print-out paper that I can have spread out
| on my desk all at once, and fold, write on, stick in a desk
| drawer for later, cram in my pocket, flip over to sketch
| something on the back, whatever.
| ryandrake wrote:
| Tale as old as time! I remember getting into almost a
| shouting match with a UI designer over this common
| conflict. Is it more important that the app's UI is
| consistent with other apps on the user's computer, or is it
| more important that it is consistent with the same app
| across all platforms (and consistent with the company's
| self-defined "branding")? I argued that the user expects
| all his apps to be consistent and look like they fit in
| with their other apps on the system, and the designer
| argued that the user doesn't care, and that our company's
| designers knew better than Microsoft/Apple/etc. about the
| best User Experience for our particular app. Seems like
| reasonable people can disagree about this.
| curt15 wrote:
| In the coronavirus age, reading printed materials causes me
| less eyestrain than reading on a computer screen.
| selfhoster11 wrote:
| This. GIMP's save/open file dialog on Windows is, for the
| lack of a better word, graphics and usability-wise
| disgusting. Confusing and fiddly controls, no thumbnails (on
| a graphics application!) If anything, they should replace the
| GTK open/save dialog with something that mimics the Windows
| one.
| ben-schaaf wrote:
| GTK(3+?) can actually easily use the platform open/save
| dialog with GtkFileChooserNative.
| juniperplant wrote:
| I don't know why the trend, but Chrome also uses its own print
| dialog by default.
| Avamander wrote:
| I kinda like Chrome's more than the alternative though.
| cvak wrote:
| Chrome's good on Windows, but on macos it's a mess, at
| least on my machines. No preview generation, weird scaling
| issues, ...
| i386 wrote:
| Some product designer in MTV needed something to do
| [deleted]
| fuzzy2 wrote:
| Meanwhile, on Windows, there's nothing left of the browser that
| looks native.
| perryizgr8 wrote:
| On Windows, no app looks "native". There seems to be no
| standard native Windows look left after years of idiotic
| redesigns and missteps by Microsoft.
| darkwater wrote:
| And this is frankly ironic because for so many years one of
| the biggest complaints against desktop Linux by Windows user
| was the lack of uniformity between Qt, GTK and other toolkits
| interfaces.
| dsego wrote:
| I doubt that windows users would care, mac users maybe.
| Number one complaint is lack of pro software like photoshop
| or ms office.
| pseudalopex wrote:
| Windows used to be more consistent. Now the Windows users
| who cared gave up Windows or gave up caring.
| mhd wrote:
| That's always been the case. After Win95 came out, every OS
| revision _and_ Office release changed the default look and
| feel. It was most noticeable in the toolbars. Started out
| with visually raised buttons (like regular interface
| buttons), then the buttons went flat, then the whole toolbar
| was raised via a gradient, then everything went bonkers with
| ribbons (meanwhile in browsers you had huge buttons with text
| below as yet another alternative).
|
| Or the checkmark/cross ok/cancel buttons that were quite
| common (Borland?).
|
| That "old" look and feel co-existing with "modern" flat/web
| designs just made the differences more noticeable, never mind
| the often associated differences in icon sizes and styles.
|
| Not that other systems are better. Linux always had too many
| widget toolkits (and now those awful upside-down window-
| title-toolbars), and even Macs always had at least one weird
| option (e.g. brushed metal or too iOS-like thingamajigs).
| fuzzy2 wrote:
| Ah but you see, all the core details remained the same
| since Windows 95. Some from even earlier. Flat buttons,
| raised buttons, buttons with round corners, they all had
| the same dimensions, margins, padding. Same goes for all
| the other details like menus. Indeed, this remains the same
| even today, in the Run dialog, Win32 applications like
| Notepad, ...
|
| Some things changed, like window chrome and the shell
| (taskbar, start menu). Ribbons came. But the core design
| language remained unchanged. Until Modern UI.
|
| The Firefox context menu is of course not "native".
| However, in Firefox 88, it has the look I would expect. The
| way it looks in basically all Win32 applications. In
| Firefox 89, context menus are inflated, comically large.
|
| Just because Microsoft is butchering UI consistency doesn't
| mean other software has to follow suit.
| Ashanmaril wrote:
| If you right-click in default Microsoft apps that ship with
| Windows, you can expect one of like 5 types of menu to appear
| satysin wrote:
| Looking "native" on Windows is a very difficult thing these
| days. To me classic Win32 is what "looks" native whereas all
| their modern apps like Mail and Calendar don't look native at
| all even though they are.
|
| Office is native but has its own, unique look and feel that is
| different to other native tab interfaces built into Windows.
|
| And don't get me started on context menus in Windows (ironic
| given this story). The design and items on a context menu is so
| inconsistent it drives me mad at times.
|
| Consistency in Windows is a real pain point imho. I would love
| for Microsoft to just stop adding more crap to the shell like
| some weather or contacts fly-out and just spend a year getting
| everything consistent with a good, modern light and dark theme
| that works everywhere. I know it is easy for _me_ to say that
| though.
| AshamedCaptain wrote:
| (Office is not native. Easy to check since all the controls
| behave in their own particular ways, even on dialogs, and the
| look is strikingly different from the rest of the system
| controls. Most exacerbated if you run Office 9x on NT 3.x).
| crooked-v wrote:
| It's easy to complain about Apple changing the macOS look
| every year, but boy, Windows hasn't had a _single_ 'look'
| since the Windows XP era...
| 2ion wrote:
| Proton will kill the native LnF on _all_ platforms in Firefox
| in a Badum! way. The context menu on Windows isn 't native
| either btw, in that it doesn't follow the OS theme. Ironically,
| on Linux, the context menu has always been properly styled
| according to the active GTK+ theme...
| Yaina wrote:
| There are a bunch of considerations for the native look-and-
| feel that go beyond the primary visual aesthetic. Using the OS-
| specific terms, shortcuts, font-sizes, button order, APIs. This
| maintenance effort is not trivial. This is all stuff people at
| Mozilla are trying to look out for.
|
| But additionally adopting the design language of the system is
| another burden altogether. It potentially triples your design-
| and implementation time and adds a lot of complexity to your
| code. And if you're unlucky the next OS version requires you to
| change it all again.
| WhyNotHugo wrote:
| Then again, most MS applications have never looked "native" on
| Windows either -- it seems each team has always gone for their
| own style and UX.
| jaas wrote:
| As someone who used to be involved in the decision to not
| implement native context menus, and did a bunch of work on the
| non-native ones, I want to try to explain why this took a long
| time.
|
| It has nothing to do with engineering resources, and we always
| _wanted_ native context menus, but they were not customizable
| enough to meet the perceived needs of web, XUL, and extension
| developers at the time. People expected to be able to change
| colors and layout with CSS, for example. The native APIs put
| heavy limitations on what you could do with a native context menu
| and it was just not compatible with the expectations of people
| building against the rendering engine at the time.
|
| There was some discussion of switching back and forth between
| native and non-native menus based on styling, but that got
| complicated quickly and it wasn't thought to be worthwhile.
|
| It sounds like perceived needs have changed, and maybe the native
| APIs allow for bit more flexibility now. Glad it's happening,
| excited to see how well it works!
| kergonath wrote:
| Thanks for the explanation. As a user I very much prefer native
| widgets, as non-native ones always break expectations in subtle
| and infuriating ways, but it is interesting to see the
| reasoning behind this type of decision.
| seumars wrote:
| The fact the modern UI design has become as homogeneous as it
| is nowadays is a blessing that's hard to appreciate sometimes.
| I have to admit I still miss the early to mid 2000s era when
| customisation was more or less expected of every application.
| abruzzi wrote:
| I don't ever want to go back to the "Kai's Power Tools" era
| of UI design. Computers don't excite me, they are a tool to
| get things done, and consistancy makes every application
| easier to learn. Granted, I know I'm probably in the
| minority, because custom UI widgets are commonplace in mobile
| app design.
| EvanAnderson wrote:
| I question the priorities of a developer who spends
| (wastes?) their time trying to dazzle me with bespoke UI.
| They should be focusing on dazzling me with the speed,
| efficiency, and reliability of the intended use of their
| program.
| fouric wrote:
| Speed, efficiency, and reliability have nothing to do
| with whether you use a stock or custom UI toolkit.
|
| As an example: the GNOME file picker is computationally
| inefficient, ergonomically inefficient, and feature-poor.
| I'd much rather use some third-party developer's superior
| replacement (if it existed).
| EvanAnderson wrote:
| I'd say that a third-party replacement kit isn't bespoke
| UI. The GP mentioned Kai's Power Tools. If you're not
| familiar, have a look at how it looked. That's the kind
| of time-wasting drivel I'm talking about.
| chrismonsanto wrote:
| > Computers don't excite me
|
| Honestly kind of a depressing thing to read on "Hacker
| News", not that I disagree that UI consistency is good
| OOPMan wrote:
| I mean...it's just the typical mindset of a Mac user
| really.
|
| I don't want a choice, just give me something with a
| chrome finish and I'll throw my wallet at your face.
| the_only_law wrote:
| > Honestly kind of a depressing thing to read on "Hacker
| News"
|
| I agree it is, but I also must say as of recently I
| agree. There hasn't been anything in a while that's
| excited me. Probably in part because I went around to
| learn how all the parts of the sausage are made.
| Cyberdog wrote:
| > Honestly kind of a depressing thing to read on "Hacker
| News"
|
| Is it? For many of us, our computers are tools we use to
| get jobs done, so stability and predictability in
| function are far more valuable than something that looks
| pretty. Ask a carpenter if he wants glitter on their
| hammer, or a plumber if they need tinsel on their monkey
| wrench (oh and also the nut screws the opposite direction
| because some programmer with UX designer aspirations
| thought that might be neat two decades ago).
| [deleted]
| Seirdy wrote:
| I think the implication was that this site was supposed
| to entertain "hacker culture" rather than "software
| development culture". I've also noticed a general trend
| from "Hacker News" to "Software Developer News", and
| sometimes joke about petitioning to rename the site.
|
| Treating a computer as nothing more than a tool to get a
| job done is perfectly valid, but other people see
| general-purpose computing as a medium of self-expression
| and something that has value in and of itself. The latter
| group understandably enjoys sharing experiences with
| others who feel a similar way. Many came to HN hoping to
| find a space for that (since the site was marketed
| towards "hackers"), but have since been disappointed.
| That's probably the sentiment that the text you quoted
| comes from.
| e3bc54b2 wrote:
| I observed myself leaning in same direction.
|
| So I thought a little in why that is, and I realised the
| constant needless worthless churn on every part of "UI"
| from every corner of OS and application has made
| discovery impossible, especially discovery on my terms. A
| new update or UI is now terrifying rather than exciting.
|
| The only two times I remember being excited about
| computers in last couple of years is when I picked up
| NixOS and Lisp. Now that says more about me than
| computers, but that's my 2c.
| barrkel wrote:
| I suspect "perceived needs" have changed due to the scorched
| earth policy Mozilla took with the old Extensions API. All
| extensions have had to be pretty much rewritten from scratch.
| jaas wrote:
| I'm sure that's a big part of it.
|
| The old-style extensions were so powerful because they could
| put their API tentacles very deep into the rendering engine.
| Mozilla paid a huge price for allowing that though - it was
| very difficult to change the behavior of many parts of the
| rendering engine without breaking extensions. Much of what
| you'd think was just internal implementation detail was
| actually API surface accessible to those extensions. The
| workarounds added a bunch of internal complexity. It really
| slowed down the pace of development.
|
| I get that some people mourn the loss of that style of
| extension, but dropping it was an important decision that
| should have happened much earlier. There were other issues
| with the old-style extensions (e.g. security) but making the
| pace of development uncompetitive should have been enough to
| doom it.
| eschaton wrote:
| It sounds like web designers need to adjust their expectations.
| When they're designing web pages, they don't get complete
| control over rendering or OS controls, and just need to deal
| with that. The idea that a web page _should_ be able to
| override things about how a contextual menu is rendered is
| laughable.
| millerm wrote:
| I'd love to have the "Look up" option on the menu. Every time I
| right click I am again reminded of its absence. So, hopefully
| "soon".
| qalmakka wrote:
| Wow, that issue is older than OS X itself, which I assume it
| means it originally referred to Classic Mac OS. It's nice to see
| it tackled after all this time, AFAIK Mozilla doesn't even
| support XUL anymore.
| athenot wrote:
| > OS: Mac System 8.5 - MacOS X
|
| Indeed, it was first described against MacOS 8.5... that's a
| memory trip!
| zarzavat wrote:
| That's funny that it was reported against Mac OS and fixed in
| macOS, skipping OS X entirely.
| quietbritishjim wrote:
| macOS is just a new marketing term for OS X (albeit a
| different revision). Whereas classic Mac OS is
| fundamentally a different OS.
| egypturnash wrote:
| Opened midway through the PowerPC era. Lingered for the
| entirety of the Intel era. Finally fixed at the dawn of the
| ARM era.
| nyx wrote:
| Leaves me feeling a little contemplative... will the stuff I'm
| logging in my project's issue tracker still exist in 2040? Will
| my project be relevant, or even remembered? Is the company we're
| working for even going to be around?
| nly wrote:
| There are still issues that come up at my work that nobody
| wants to tackle because that part of the company is running off
| fortran.
|
| I predict JavaScript will be the Fortran of 2040
| slver wrote:
| JavaScript isn't going anywhere, I believe.
|
| And I'm not saying this because I think it's the best ever,
| or because I don't learn from history and how things change.
|
| It's the nature of the web. We're still dragging things from
| HTTP/0.9 and and from HTML 1.0 along.
|
| But _also_ , JS is a capable script engine with millions of
| USD put into engineering VMs into it, and the networks
| effects are inescapable. I don't see WASM replacing it
| either. They'll be used in tandem.
| dkdbejwi383 wrote:
| If I can get the legendary FORTRAN sacks of gold, I'll
| happily take Promise.then.then.then.then in 2040
| TeMPOraL wrote:
| I think the time to get rich off JavaScript is now - I hear
| webshops still pay ludicrous salaries, but junior web
| developers are being manufactured in great quantity, so the
| market will eventually saturate.
| capableweb wrote:
| As all markets, juniors are everywhere and easy to hire
| but what companies really want are good developers, and
| those will always be hard to find.
| DonHopkins wrote:
| All the good COBOL developers had themselves frozen.
|
| https://donhopkins.medium.com/cobol-forever-1a49f7d28a39
| TeMPOraL wrote:
| Another way of looking at this is: it's a great life
| extension hack!
|
| One of the problems with cryonics is, how to motivate
| future people to revive you in the first place? Learning
| (and having it documented) a technology on which global
| economy is going to be critically dependent for decades
| to come sounds like it should do the trick.
|
| (Another problem is, how to motivate earlier future
| people to keep you around until your value becomes
| apparent, which will likely happen only when your
| services are direly needed on short notice.)
| VortexDream wrote:
| I still regularly see code here that's 10-15 years old and some
| code that's older than the company itself. It's both surprising
| and a bit scary to see how much code is still flying around
| that hasn't (or has barely) been touched in so long. Or even
| the idea that code can transcend companies and end up in
| entirely different places.
| pjc50 wrote:
| At my previous workplace some of the copyright headers said
| 1991.
|
| However, it had been through the source control of Theseus; CVS
| -> SourceSafe -> SVN. When I left there was talk of moving to
| git, but since the build system checked in binaries that was a
| serious obstacle. The bug tracking similarly had been through
| at least one reset.
| slver wrote:
| How does that matter to you
| marban wrote:
| About that color management thing...
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=455077
| slver wrote:
| "Hey, why not use native context menus?"
|
| "I can't argue, but it's a time thing."
|
| 21 years later...
|
| "Fixed."
| kevingadd wrote:
| Judging by the massive number of dependency issues (bugs, etc)
| that appeared in the bug history once they started working on
| moving to native menus, I guess it really _was_ a time-
| consuming thing to fix :)
| amelius wrote:
| If the menu was already implemented in a generic (non-native)
| way for other OSes, then making a specific native
| implementation for one OS is more work and thus more time.
| modeitsch wrote:
| But I don't use them any more only brave
| jez wrote:
| Just downloaded the beta. I was hoping this meant that right
| clicking on selected text in Firefox on macOS would let me look
| up the word in the macOS system dictionary (e.g., in both Safari
| and Chrome, if you right click on a selected word, the first
| result in the context menu is `Look up "<word>"`).
|
| It's such a convenient way to learn new words (and even works
| across multiple languages). Alas. Maybe in a future update!
|
| (Another, similar, gripe is that both Safari and Chrome, along
| with most other native macOS apps, will select the word under the
| cursor with just a right click--no need to even double click to
| select first and then right click. Firefox doesn't do that.)
| dieortin wrote:
| You can tap the word with three fingers to look it up in the
| dictionary (you might have to enable it in trackpad settings)
| perryizgr8 wrote:
| You can just use the search option in the right-click menu.
| Google will give you the definition of the word for most words
| you actually want the definition for.
| tzs wrote:
| A couple workarounds.
|
| 1. Select the word and hit ^[?]D or [?][?]D. The former opens
| the definition in a pop-up, the latter opens it in the
| dictionary app.
|
| 2. There is an extension that adds a context menu item that
| opens a new tab on the Oxford definition of the selected word
| at lexico.com [1]. The same extension author also has one for
| the Cambridge dictionary.
|
| [1] https://addons.mozilla.org/en-US/firefox/addon/oxford-
| englis...
| hamandcheese wrote:
| If you use a Force Touch capable trackpad, force touching a
| word opens the dictionary.
| adwww wrote:
| I'm amazed anyone finds that useful. I've had to disable it
| due to constantly accidentally activating it.
| hamandcheese wrote:
| I almost never accidentally force click. You can increase
| the force required before it activates in settings.
| richardwhiuk wrote:
| Tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1116391
| abdusco wrote:
| You can force click a word to trigger dictionary lookup. But
| I'm not sure how to get it working with a selection rather than
| only the word under the cursor.
| wodenokoto wrote:
| This has been fixed recently and force clicking will look up
| the selection rather than try to do a Smart Selection.
|
| I don't know if it's an macOS fix or Firefox fix, but it
| works like you'd expect now.
| wraptile wrote:
| Alternative recommendation I have is to setup launcher/terminal
| script for word definitions - retyping the word aids with
| memorization!
|
| For MacOs I use Alfred launcher and just click option+space
| "define myword"
___________________________________________________________________
(page generated 2021-05-25 23:02 UTC)