If I'm reading the issue thread correctly, it seems that a big revision of the hit testing code was being field trialled (ie enabled for 1% of stable users) and a fix to that code in Chrome 77 caused a bug for the other 99%. Unfortunately, this new bug was only discovered partway through version 77's rollout.
So now there's a bit of a pinch: revert the fix (and break it for the 1%), or leave it (break it for the 99%). Presumably, you could disable the field trial AND revert the fix at the same time, but that wasn't considered. I'm not sure why, but my guess would be that it's a pain in the butt to coordinate both rollout systems.
Obviously the right answer is to make a new fix that doesn't break things for any users, but fixes take time and the release was already halfway rolled out. I think that's where the discussion about impact came from, and the initial assessment was that it wouldn't break much stuff, so the fix was bumped to the next release (Chrome 78).
However, after lots of people jumped on the issue tracker to say it did, in fact, break a bunch of stuff, Chrome 77 was re-released ("respun") with the new fix included.
So, broadly speaking, I think the decisions here made sense under the assumption that it was a small-impact issue. My main criticism would be that there must be a more effective way to estimate impact than waiting for people to complain in the bug tracker.
One approach would be some kind of reverse integration testing system. ie, if you have a critical app or library that depends on Chrome, there should be some way of submitting your tests so that the Chrome team can estimate the impact of changes and find out more easily if they'll break anything unexpected.
>...My main criticism would be that there must be a more effective way to estimate impact than waiting for people to complain in the bug tracker.
This is very true. There are 100s if not thousands of people for every support person that knows about new Chrome updates and Bug Tracker for opening issues.
Users are told to trust Chrome updates and assume that updates won't affect existing functionality and so the idea of opening a browser support ticket does immediately come to mind.
Spent half the morning trying to work out why drag and drop events were not working properly in code that was working fine and deployed for nearly a year. Finally tracked it down to this obscure bug in Chrome 77 which re-orders drag and drop events but only when your page is inside an iframe that is hosted on a different domain. Looking at the report it looks like this has broken a lot of peoples applications and likely a lot more that haven't yet worked out this is the reason. Looks like a fix is coming in 78 fortunately.
I work on drag & drop a lot, especially right now. It's interesting how complicated overall, and how many different (code) solutions there are to the general drag & drop UX problem. I was consolidating ideas/notes from older notebooks a few mornings ago, I couldn't help thinking how it feels like reimplementing human evolution in a different/abstract medium.
To me it's very interesting to see how many applications completely forgot that you might want to use a scroll wheel during a drag and drop. I don't think that even works half the time...
Yeah, I can attest to this. It sounds easy at first, but suddenly you need to handle items inside virtual lists (e.g., react-window), scrolling, data updating while dragging, ...
That’s exactly what you think going in...that’s the point I’m making.
No one is hand rolling drag and drop these days.
There’s a lot of complexity implementing drag and drop both visually and binding stuff to events. It’s messy and finicky. Unless your usecase is very simple.
To add to sibling's point, many drag-drop libraries work great on a bare demo website with nothing else to worry about.
Once you start trying to add it to your frontend with other complex features already there, you're back having to reason about the core of drag-and-drop and essentially solving it yourself to parse the library's code. In my experience I've had to modify library code to handle my requirements most of the time because it did not play well in a complex environment.
I've been tracking this drag-and-drop bug from five years ago; it's still not fixed.
I think most browser manufacturers mostly gave up on the HTML5 drag-and-drop API. There are lots of open bugs on lots of browsers that haven't been touched in ages.
Well that makes me feel better AND worse about the one I filed a year and a half ago. (Drag events aren't dispatched at all on option elements in a multi-select, which is such a shame because a multi-select seems like the best native form UI for users to create orderings & permutations...)
I switched to Firefox after they stopped caring about usability issues (like right clicking without releasing left mouse button deselects the text since v fifty-something on windows), the difficulties they created for ad blockers, the account integration fiasco, and so on.
I know this particular bug seems to be an edge case that may happen with every browser, but when you are using Chrome, you should know that if an issue doesn't affect Google, it will likely be deprioritized a lot.
I'm not a self-acclaimed internet freedom fighter, I'm actually very pragmatic, and I'd still humbly suggest everyone to give Firefox a try.
Given that Chrome ended Opera, and is effectively ending IE/Edge, people really need to take pause and appreciate and be thankful that Firefox is still around. I think the "shady shit" Mozilla has pulled lately are death rattles. I certainly don't expect it to be around in another 5-10 years.
Firefox's tiny market share is all that stands between all the W3C and WHATG publications going from "standards" to "what Chromium does".
Google is a giant corporation. One day they're going to do an IE6, and shift their focus away from the project, and the whole web will suffer.
"Doing an IE6" for Google would be quite different from what Microsoft did, who wanted the desktop to stay relevant. For Google the web is just an advertisement platform. If/When Firefix is gone, they will hold all the cards. "Doing an IE6" might mean removing support for ad-blockers. Or making Google DNS mandatory. Or have everything you do on the web be phoned to Google, to improve your advertising experience. Assume they will find creative ways to monetize the web, ways that we didn't even think of yet. If you thought the web in 2019 was bad, beware of the Google Future.
AMP seems to be an example of the kind of web that (some parts of) Google wants. Hosted on their servers, transformed by their tools, commoditized and sanitized for ad insertion.
Today when you navigate to google.com from Microsoft Edge, there's a barrage of popups urging you to use Chrome instead.
When Chrome is completely dominant, maybe those popups will be on non-AMP sites urging you to "get the best experience"? It's guaranteed that there will be a lot of internal pressure to use Chrome to promote the goals of other divisions at Google.
Why did MS want to do an IE6? For power and control. You imply a difference in your statement, but it's only a matter of time before it becomes too seductive to resist.
It only needs to make sense in the minds of a handful of high-level managers, and we all suffer.
Why is that a problem? I never got the furore over it. When it appeared, I removed the icon and just went about my business.
Annoying yes, but certainly not "shady". From what I understood / stand it was a mozilla app they included with the browser, not that different to how firefox comes with a bookmarks app.
Yes, if you're familiar enough with Firefox that you know where to click and are comfortable enough to experiment with customizing your browser. I don't think that's the case for most people.
It took me a few months before I realized that the page was customizable at all, especially since the triple-dot menu doesn't even show up until you hover or focus the element.
How about enabling DNS-over-HTTPS, which routes your entire browsing history to a third party, based on selections labelled "OK, Got It" and "Disable Protection":
Don't get me wrong, DoH is great if you have a shady ISP. But it should be opt-in, not opt-out, since those of us who don't have shady ISPs don't want all our DNS queries centralized in the same place, to be scooped up with just one FISA warrant. And dark patterns like this are a pox on the web and Mozilla shouldn't be perpetuating them.
Your complaint is about a Web Extension Experiment that they're currently testing and not a feature they have shipped in the browser. It seems like this isn't shady at all, but rather they're testing something and soliciting feedback. You provided some and they responded that they plan to write a blog post about it.
So what's shady here? That the process is working?
I still don't think its shady. Mozilla have publicly stated that its possible to change the DOH provider, and furthermore they have clearly laid out their requirements for Cloudflare to participate in this experiment. This seems like a good compromise in order to force other providers to start encrypting dns requests.
"OK, Got It" and "Disable Protection" is pretty accurate.
It's inconvenient, but it turns out the "open, anonymous" web has huge trust issues that bad actors use to exploit and attack the unknowing. Some of that is most readily solved by nudging users to trusted third-parties.
You can have issue with whether that third party should be trusted, but the larger issue is that the user has to trust some third party for DNS to work at all, and most don't even think twice about that question.
> since those of us who don't have shady ISPs don't want all our DNS queries centralized
If you don't hae a shady ISP, disable protection. You're already protected by your ISP not being shady, right? ;) The average user has no idea if they should trust their ISP's DNS.
>One day they're going to do an IE6, and shift their focus away from the project, and the whole web will suffer.
This would still be preferable to if they became the only browser and all web developers were subject to breakneck paced new features and discontinued compatibility as Google makes their characteristic impulsive lurches with zero long term vision.
I think a lot of the shady shit y'all are all complaining about are annoying, but not anything CLOSE to the kind of red flags that should call for the end of a product.
Bad decisions does not imply evil decisions, nor does it imply death. Pocket? A convenience people may want that might have provided money, hat didn't invade privacy. DNS over HTTPS? The horror! They are trying to enhance privacy on the Internet but haven't done it perfectly!
> I'd still humbly suggest everyone to give Firefox a try.
I usually suggest die-hard Chrome users use a plugin to spoof their user agent so product managers and developers are more likely to tread non-Chrome as a first-class browser.
I guess it's better than nothing but 1.) it will cause pages (especially some Google properties) to deliver unoptimised versions meant for the real Firefox (or more generally non-Chrome browsers), and 2.) don't sophisticated websites and apps anyway ignore user-agent string and directly probe through JS?
I switched back to Firefox from Chrome with the introduction of Firefox Quantum after years of failed attempts at switching back prior to that. Firefox really is first class again. I echo your suggestion to give it a try again.
> I know this particular bug seems to be an edge case that may happen with every browser, but when you are using Chrome, you should know that if an issue doesn't affect Google, it will likely be deprioritized a lot.
Not to be that guy, but if you take a look at the bug a fix has been merged into 77
And this is why I take rants against Google and MS with a grain of salt.
Top voted comment couldn't bother to read bug report. I often see inconvenient truths buried in downvotes meanwhile misinformation that apeases a vocal minority gets catapulted to the top.
I've read the report. I knew about the merge. This issue has been postponed until developers started reacting aggressively, so breaking all drag and drop in iframes was nearly okay until a new version was published. When the issue is affecting users, it gets worse: The small number of them who could navigate their way into creating a chromium bug report will be waved away.
I respectfully disagree: Try to explain your users that they won't get drag and drop for 21 days. This would have been worse if there weren't passionate people aggressively following it.
A Google account integration issue would always be more important than web pages being broken in many subtle ways. This wasn't the case when they didn't hold the browser monopoly.
Did Mozilla take 21 days to fix that issue, push it off for a future release, and only reprioritize it as a hotfix after being hounded?
GP isn't complaining that Chrome has bugs, every browser has bugs. They're complaining that Chrome doesn't prioritize bug fixes unless users raise a stink.
I am somewhat sympathetic, because I've worked with issue triaging, and I understand that everyone wants their issue to be #1. I am less sympathetic than I otherwise would be though because Google owns the dominant browser in the marketplace and is owned by one of the biggest companies in the world. My standards for them are higher.
Firefox could be a lot better with usability issues, too. They will agree on something being an issue and then let the ticket sit there for months and years, even if it's something that's easy to fix and should be prioritized.
"should be prioritized" is a very subjective statement. Out of every 100 tickets, there is 50 people who believe theirs is the most important one. And we have over 200k tickets total (not all are bugs, many are resolved, but the scale is massive).
If you think a bug is easy to fix, pleasez consider providing a patch.
I find it hard to believe you don't know that casually contributing to Firefox is ridiculously hard. The build system is borderline insane, building takes hours, and most importantly people who can approve your changes clearly have more important things to do and regularly fail to answer. I have tried contributing a couple of times. Thank you, no more.
I casually contribute to Firefox and it's not ridiculously hard. It is a somewhat steep learning curve if you contribute for the first time, primarily getting acquainted to the build system, the area of the code you're fixing, and then finding the right people to nag about reviews, but it is far from ridiculously hard.
It used to be ridiculously hard, back in the days of hq merge queues or even cvs, I give you that, but the general build stuff improved a lot since then.
The build system is hg clone/git clone + ./mach bootstrap + ./mach build... And there is a lot of docs for it too. I wouldn't call that "borderline insane".
Submitting a patch for review is a only moz-phab command away (after you set it up once, which took me under half an hour).
A full build on a slow machine can take hours indeed (on my 2015 macbook it takes about about 2 hours I think, but my beefy desktop finishes in under one hour). But you often do not even need a full build, but an artifact build[1], which brings it down to a few minutes and just a few seconds on rebuilds (./mach build faster).
>and most importantly people who can approve your changes clearly have more important things to do and regularly fail to answer.
Now that's actually a problem. It's usually not that they are too busy to respond, but that they do not read their bug mail (because they get thousands of emails a day). That's why you either have to actually request a review or need-info them on bugzilla. That usually draws their attention, simply because review requests are listed in a neat list and need-info-s are listed in another neat list, and if that still fails to grab attention, there is enough folks on the irc channels who can either help you directly or point you in the right direction.
./mach bootstrap will usually help you set up your environment mostly automated after some confirmations, and will ask you if you want to do full builds or artifact builds, too
Compared to other software of similar complexity I think standing up a Firefox build is actually pretty reasonable. The bootstrap instructions are not complicated (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...) and the build takes about an hour on my laptop. Chrome is certainly a lot harder and takes significantly longer (if you lack access to Google's internal build farm). Likewise the Linux kernel is also tricky and slow to build the first time.
I have found contributing to the linux kernel a significantly more pleasant experience than contributing to Firefox.
I have no trouble believing that contributing to Chrome is even harder, but then again I didn't hear someone from Google saying "If you think a bug is easy to fix, pleasez consider providing a patch."
I mean, Google doesn't even pretend to be open to community contributions. Pretty much every choice they make is tailored to googlers only, just look at their build systems. They're upfront about it which I think prevents me from complaining about how hard is to contribute.
I'll take Mozilla over Google every day, but if Mozilla presents itself as open to community, it also lends itself to criticism that Google avoids altogether.
So yes, that happens, and if that's not as easy as we could have hoped, probably help is welcome with that as well.
Big and complex projects generally have higher standard of effort necessary to get the leg in. The comparison to Chrome was that it's a project comparable in complexity, and yet Firefox is easier and faster to build.
I've submitted many browser bug reports to Google, Microsoft, Apple and Mozilla over many years. I only bother to submit issues for "important" bugs, I write clearly, I simplify, and I spend significant time ensuring that the bug report is useful to developers and relevant for users.
Google respects my efforts, and often fixes my reported issues, or at least explains why it can't be fixed (usually with well reasoned answers, usually the actual developer is communicating with me).
Microsoft/Apple/Mozilla waste my time, ignore my efforts, and generally that results in a poorer user experience in the browser.
The Chrome team is one of the most amazing software teams I have ever been tangentially involved with - and the product quality shines.
I suggest Mozilla look at the last 6 months of bugs submitted and do some analysis on them.
Ideally take a subsample and talk to the submitters, and see what they think.
If Mozilla agree that Google do a better job than Mozilla, then benchmark against them.
I eventually stopped reporting bugs to Mozilla, Microsoft and Apple unless I absolutely had to. I recently stopped working with browsers, so I no longer have much appetite for helping.
I consider that vastly better than the Chrome approach, which just robo-closes all bug reports more than X months old and tells you to open a new ticket if you still care. This happened even if there was traffic on the ticket indicating that yes, it was still an issue and affecting multiple people.
I stopped bothering raising Chrome bug reports years ago.
If it's a js/css/html/xul-only fix (and chances are good it is, when it's a usability issue, as the frontend/UI code js on a high level), then you do not even have to really build Firefox but can use artifacts mode[1], which takes a few minutes for the initial build and only a few seconds for subsequent builds.
Then find a reviewer. I usually look at the recent activity of files I touch (or related files, or related bugs), find functional changes and just add whoever reviewed those most recent changes. Even easier when it's regressions, then you can see who reviewed the regressed changeset and who wrote it and CC them as well.
If the person(s) you picked do not want to review it or cannot review it, they will tell you, and usually suggest who else to ask.
If this doesn't work, then you can always ask/nag on IRC.
I've recently started using FF for some uses, and find it quite laggy compared to Chrome (on Windows, even with dozens of extensions, and heaps of open tabs in Chrome, and one or two tabs on FF). I would like to use it, but performance wise doesn't seem to do for me, unfortunately.
Firefox already ships some UA overrides. You can see the list of active overrides (with links to bug reports explaining each) in Firefox's about:compat page.
Well browsers with a different engine do work differently. By the way, I do disagree with this strategy. Just saying it is not necessarily something illegal.
Problem was in this case it seems the product works fine across different engines, they just decided it was ok to block a competing product to limit comsumer choices and generally make the web a worse place ;-)
Of course it doesn't have to be that black and white but they certainly makes it easy to dislike them at the moment.
Mostly because M$ has a browser based on Chrome after failing to gain significant market share with their own and supporting 72% of the browser market share (Chrome + Edge) is good enough for them. Maybe if more people used Firefox, they'd be persuaded to support it. Currently Firefox usage is around 9.2%.
I'm using Firefox so it doesn't work for me either. I was using their web app before they decided to ditch Firefox. Now I am forced to use their stupid desktop app. If they decide to push ads I will just tell my colalborators to contact me via e-mail or switch to Wire.
> if an issue doesn't affect Google, it will likely be deprioritized a lot.
And in Firefox ? someone still needs to prioritize issues, and issues affecting more people will get more attention in both browsers.
As an immigrant struggling with a new language personally I need Chrome's right click to translate a page functionality in Firefox before I'll fully move
Simply select text, click the popup and done. I just wish there was option to quick change the output language (currently you can have like 2 target languages).
> I know this particular bug seems to be an edge case that may happen with every browser, but when you are using Chrome, you should know that if an issue doesn't affect Google, it will likely be deprioritized a lot.
For what it's worth, I've found them responsive to my bug reports, and even my feature requests.
I've noticed recently that the configuration for Mozilla is actually more difficult to disable all the privacy-impacting options and they are in more obscure locations, than with Chromium. The only exception being once you enable sync in Chrome-based browsers it will add additional options that then have to be disabled as well.
Subjectively, most of the performance regressions I've had have been in Firefox, sadly. They had an issue that absolutely torpedoed flexbox performance for quite some time, for example. It has since been resolved, but it's still the leading cause of performance complaints I see from my users.
> ...after they stopped caring about usability issues...
The bug is already fixed and has been released. What other issues are you talking about?
I trust Mozilla less because they’re more desperate and desperate people are dangerous. They’re also ideologues who I don’t agree with, who often say one thing and do another. They preach privacy/control for users while simultaneously selling them out, removing control and inserting ads where there should be none.
Love the random comments in the bug tracker. "We have an enterprise-level software affected, what is the ETA?"
Lots of folks just figuring out web apps don't run in a metaspherical happy place or "the cloud", no, they run on fucking Chrome and you are not paying for it.
Tomorrow everyone on Hacker News and Twitter will go back to chiding IT departments that want the ability to test software changes before they get deployed, or have the ability to roll back.
In fairness, when was the last time you read a story like this one?
Chrome updates constantly and regresses nearly never. It's actually impressive how rarely this happens given the complexity of HTML. Slow IT departments delaying useful upgrades is an everyday occurrence though.
Could be. OTOH if a bug in Chrome affects only one not-well-known site, then it is neat that the engineers bother discussing the mitigation and providing support to the dev of that site.
Funny, my company has been developing an application that suddenly behaved bizarrely in Chrome 76 (some divs were constantly jumping up and down the page, augh). We pulled our hair on this problem for a week, then suddenly Chrome 77 corrected that... But apparently it's broken elsewhere?
I've been dealing with a massive performance regression in the canvas API. The frustrating bit is that they were well aware of the cost and made the change anyways. They didn't seem to stop and consider what effect it might have on major libraries and applications.
No, you are just not understanding the tradeoff. They fixed some canvas not being accelerated when they should have been. This means they can be hardware composited, drawn to and need to only exist once as a GPU texture. This is a massive win for performance and power consumption.
Here is what is not efficient, ever: getting a GPU texture into a raster format CPU accessible buffer. At best this requires synchronization and a full memory copy into a new buffer, but it can easily be much much more expensive because GPUs, and mobile GPUs basically never, store textures in raster formats. So now you need a full copy and a bunch of extra SIMD to convert it from the GPU preferred format into raster format for your getImageData call.
And all this for what is essentially a trap API! Chances are if you are calling getImageData regularly, you are doing something wrong and inefficient.
> Chances are if you are calling getImageData regularly, you are doing something wrong and inefficient.
I would love to see stats on the use cases. Personally I have never used canvas other than to getImageData in a loop!
If I only needed to draw primitives, SVG is often a better choice.
If I needed something GPU accelerated, I would switch to webgl and write shaders.
So the only thing left 2D canvas is good for is to get the pixel data to do image processing on (e.g., flood fill connected components, color histograms, etc).
Chrome 77 did waste 1 day of work for me though, I filed a bug report related to drawImage canvas-to-canvas on large files and they merged a fix for my issue pretty fast:
Interacting with googlers is horrifying. He was ready to commit to the bad decision until he was threatened with a PR disaster of breaking the software used by "hundreds of thousands of school kids".
I can't help but think that if a lowly dev like me were to report the issue the "won't fix" would've stuck.
Hundreds of people saying "My app is broken" isn't data. Someone saying "based on a search of the top Alexa 1 million sites, this will affect 8% of users" will catch their attention.
As a Chromium developer speaking based on my observations, we're also responsive to fixing bugs that affect a small percentage of sites. The difference is prioritization, and whether we'll merge fixes back to stable branches for a respin.
Probably more a case of me never having tried than anything else because I'm sure someone will have solved it, but end-to-end testing of drag and drop sounds pretty hard.
It isn't. Jest and Puppeteer are my current choice, and it's really just a matter of sending mousedown, mousemove, and mouseup events to the browser and checking the expected behaviour is right.
It makes a huge difference to how long you send testing manually.
While we're on Chrome bugs am I the only person in the world running into this bug in Chrome that makes it DOS the entire machine? You can repo on an NVidia MacBook Pro. Go to stackoverflow, try to make a new code snippet it (click the snippet button in the toolbar), then try typing in the snippet (hold a letter key and watch it repeat). You should notice some bug related to drop shadows ends up DOSing the GPU and the entire system runs slow. The bug has existed since around June. They claim to be trying to fix it, or rather ship the fix that already exists but needs testing, but I'm just surprised I seem to be the only person who runs into the issue. (The subset of people who write snippets on stackoverflow on an NVidia MacBook Pro). No idea what other sites are affected. If more sites are affected that would raise the priority for fixing. If most people are not affected then it's reasonable it's not a high priority.
I had to fire up Epiphany recently just to do drag-n-drop graphics assets management in the Steam app admin page.
Both Firefox and Chromium were broken, when I contacted Steam's support they said I am the only person having problems.
When I dug into the failure a bit in Firefox the object coming with the event was always NULL, and searches turned up a bunch of results from web devs struggling with the same problem in various ways.
I'm glad Epiphany worked, so I could promptly forget it all and get on with my life. Presumably it's still broken for steam app devs however. It escapes me why Valve doesn't have a simple file browser button fallback for when this crap doesn't work.
The way Chrome displayed flexbox stuff permanently changed at some point after version 70, breaking an app of mine that had been working fine for years.
> "I wish the reporter could elaborate more on whether there are live websites broken due to this or is it a project under development so we can measure the impact more."
Wasn't this specific version of Chrome rolling out to production users world-wide? Clearly there was a subset of users that was impacted by this (otherwise, a report wouldn't have been made in the first place). Not sure why they're asking the reporter about the state of their specific project?... :\
For the last few weeks, Chrome 77 breaks very badly when there are more than 255 failed websocket attempts: https://bugs.chromium.org/p/chromium/issues/detail?id=100624...
Even refreshing the page doesn't workaround the problem (you have to open a new tab). This has been causing a lot of trouble for long running single page applications that use websockets. Fortunately, a fix is being rolled out right now for Chrome. We've also been getting reports of this other websocket connection issue breaking SPA's.
I have a very old Macbook that I keep around for occasional use. The latest version of Chrome has a serious performance problem with it. Every click on a web site brings up the spinning cursor and there are several seconds of latency. Safari on the same computer has no such problem, so it's not the age of the machine.
I reported the issue, after navigating several-second UI lag, but not holding my breath for them to fix something on an old OS/hardware.
It seems like every release of a Google product(the ones that I use anyway, gmail, Chrome, Voice) brings some downside/regression.
Can anyone recommend script blockers for Safari ? It was the main reason to use Chrome for me.
It seems like drag-and-drop is out of fashion. I think big reason is that it really cannot be done well on touch-screen devices and touchpads. I don't really complain, because I have always found d&d rather impractical (and it's also terrible for accessibility); unfortunately, there are some applications that still rely on it a lot.
(As an aside, what bothers me more that the right-click menu goes out of fashion. That I feel is a bigger usability problem.)
Good for you! I personally find it difficult to do it without a mouse.
And even with mouse it's error prone, you might accidentally move your mouse during clicking on something, and d&d something somewhere that you don't really want to (classic example is moving folder into another folder in the file open dialog).
A customer of mine uses Kanbanize to organize software development. Think Trello on steroids. I imagine that instead of dragging cards to their destination we could open a menu and select the destination column. Maybe that would be even faster sometimes. However reordering cards inside a column without drag and drop would be a pain: Move Up, Move Down buttons, no thanks.
> I imagine that instead of dragging cards to their destination we could open a menu and select the destination column. Maybe that would be even faster sometimes.
In Azure Devops (Or Microsoft Team Foundation Server, for the old-timers), you can do this.
And the people trying to twiddle the menus are orders of magnitudes slower at operating the board than people simply dragging things around.
I don't disagree, this is a great example. I think d&d can work in special cases where the distance for the item to travel is not too small (so that you wouldn't move things by accident), but it is also not uncomfortably far away so that you don't see the target and have to navigate to it while you're d&d-ing. I guess these limiting factors are what makes it tricky to get right.
But what about selecting a card and being able to move it around with the keyboard?
Click to select and move with arrow keys could be OK. We should measure times but my gut feeling is that if I already have my hand on the mouse or touchpad (in my case it's always a touchpad) then I can keep using it to move the card around without the extra time to reach for the keys.
Gut feeling again: the keyboard could be more effective on larger distances because each tap of a key is a full movement of one row or one column, and no mistakes.
People using a mouse probably need more time to release the mouse and move their hand back to the keyboard, unless they are left handed: mouse on the left and right hand already close to the arrow keys.
About drag and drop: it's a mess if you can't see both source and destination at the same time. Then you drag hoping to be headed into the right direction. A right click menu could be better in those cases.
Click to select and move with arrow keys could be OK
Oh god no. Like you already state, most people operate both the mouse and the arrow keys with the right hand, so your proposal adds a lot of unnecessary movement. It could work with click to select and with WSAD keys, but most office users wouldn't discover that mode.
I would much prefer navigation keys (arrow keys, page up/down, home, end) to select, shift+navigation keys to move.
My proposal was probably not very clear. The idea is to allow both mouse and keyboard navigation. Which combination of arrows? I'd add hjkl to the list (vi and rogue like games.)
We know very well that well-designed keyboard UI can run circles around mouse-based one in a typical application. If you're a user of a "Kanban board", you're not some aunt with a phone, you are most likely in the office and you can learn to use the keyboard productively in the productivity app you use every day.
> If you're a user of a "Kanban board", you're not some aunt with a phone
No. Instead it means you are a project manager, and that often implies that your technical skills are on the same level as that aunt, maybe slightly better, but not by much.
> you are most likely in the office and you can learn to use the keyboard
Or just keep using drag'n'drop which is the established pattern, which also works really well for this, with the mouse you already have in the office.
> No. Instead it means you are a project manager, and that often implies that your technical skills are on the same level as that aunt, maybe slightly better, but not by much.
I am not a PM so I couldn't care less, but I think this is really condescending to people who work in that role. If you're a knowledge worker, it's your responsibility to make yourself familiar/efficient with the tools you use daily.
> > If you're a user of a "Kanban board", you're not some aunt with a phone
> No. Instead it means you are a project manager
Actually there are no project managers using Kanbanize at that customer of mine. They have exactly one developer and currently three freelance developers working remotely. All of us use Kanbanize every day because it's the place where we write the specs of what we have to do. One of the partners use it to answer our questions but I don't think he moves cards around.
The clear solution is to be able to drag something to a temporary location.
For example, a Trello card I should be able to drag to the home button on my iPhone, then switch apps, maybe go do something else for a bit, and then continue dragging it into an email, or HN comment.
Drag and drop should be more like universal cut and paste. It should be against intergalactic law to implement it all yourself so you can't drag between apps.
Select card by clicking, moving it to the destination by clicking to some other specific place.
Advantage of this to d&d is that you can navigate around during the process. You can easily scroll the screen if it's too large. You can for example select a different card. You can switch to different window and do something there.
The short version is that the value to devs was offset by the cost borne by every user (those components were in the binary even if they were never used, and they pulled in libraries that weren't used by anything else) and the increased attack surface of having that tool in place.
No, that's the problem. The individual items in the specification were written in a human lifetime. Full testing of the specification requires consideration of the power set of those items.
(I mistated earlier when I said unit tests. Determining if the right order of events is fired is probably a functional or integration test. And full coverage on those is the problem of covering the power set of features of a system.)
Jokes on them, I still use Chromium 67 from chromium.woolyss.com. It's the last version before WebRTC became unremovable. Now it's impossible to download this version, only the new ones. Woolyss should have kept it, like they keep Chromium 49, the last version before Chromium stopped running on XP and Vista. And I understand the risks of running an obsolete version, but it's a trade-off. For some time I was thinking of updating it, but then Google came up with lots of anti-consumer browser-crippling features.
Not disputing this, but the UX of navigating to a bank's website using Chrome on XP and getting redirected to a "Download Chrome" link when there isn't a newer version for your OS isn't a great experience either.
So now there's a bit of a pinch: revert the fix (and break it for the 1%), or leave it (break it for the 99%). Presumably, you could disable the field trial AND revert the fix at the same time, but that wasn't considered. I'm not sure why, but my guess would be that it's a pain in the butt to coordinate both rollout systems.
Obviously the right answer is to make a new fix that doesn't break things for any users, but fixes take time and the release was already halfway rolled out. I think that's where the discussion about impact came from, and the initial assessment was that it wouldn't break much stuff, so the fix was bumped to the next release (Chrome 78).
However, after lots of people jumped on the issue tracker to say it did, in fact, break a bunch of stuff, Chrome 77 was re-released ("respun") with the new fix included.
So, broadly speaking, I think the decisions here made sense under the assumption that it was a small-impact issue. My main criticism would be that there must be a more effective way to estimate impact than waiting for people to complain in the bug tracker.
One approach would be some kind of reverse integration testing system. ie, if you have a critical app or library that depends on Chrome, there should be some way of submitting your tests so that the Chrome team can estimate the impact of changes and find out more easily if they'll break anything unexpected.
Rust does this with a system called Crater: https://rust-lang.github.io/rustc-guide/tests/intro.html#cra...
And apparently Yocto has something similar: https://lwn.net/Articles/788626/