Oh silly, I see we're passing PropertyList into ObjectBoxView anyways. Alright, should be able to figure this out after kiddo bath time.

Still not sure how to do this, initial plan was to just push the button up into the header, but I forgot that headers already have their own buttons (not often, but somethings like on the current project homepage). It's still likely the best place for it, just not sure how to make this auto-magical.

Yeah, I think it's just:

Is this just a hidden button on ActionListView that gets some display: block and negative margin when on mobile? I could probably build that.

Yeah I think #2 is better.

Alternatively could have a little menu on PHUIObjectBoxView appear on each section, though I can't imagine how to make that happen automatically.

Specifically, you want things like "Edit Task" in the application menu?

Alternatively could have a little menu on PHUIObjectBoxView appear on each section, though I can't imagine how to make that happen automatically.

I'd want to move these out of crumbs and into ApplicationMenu by default, that is any action link added to a page, also gets built into the mobile menu. Further since some pages have multiple sections of action links, we'd need maybe some label or dividers automatically built as well.

I mean more from a psychological point of view it feels faster. The UX now is page load (new task) page load (submitted task), so 2 page loads to submit a new task. Where with a dialog (even is same end to end time) the user only experiences one page load change (submitted task).

When loaded as raw pages, the "New Conpherence" page is >2x faster for me than the "New Task" page:

I guess Conpherence only exists as a dialog.

Should I say it feels quicker to be a dialog? I have no actual data on the speed, just that I was very happy with the UEX of the Conpherence Dialog.

Basically, the proposed solution increases the complexity of the codebase (all the create pages need to have dialog rendering paths) and only improves the situation if the page frame has a significant performance issue. If it does, it sweeps it under the rug in a non-general way that applies to only one relatively rare workflow.

The cost of the page frame should be so small that it never motivates a page -> dialog change. If it isn't, this task should be "remedy performance problems of page frame", or if we can't we should merge it into T2086.

(do we fake it?)

Is it? I'd assume a dialog at least isn't building an entire new page?

Isn't it exactly the same speed?

There is already a task for this somewhere... if I can find it.

We should make middle clicks work as expected though, regardless.

We already have planned several UI improvements to Typeaheads, see T1906 and T6579.

A more specific use case: when I am adding a new task and am unsure whether it fits into a certain project, typing that project name in the search box and middle-clicking would be a convenient way of checking that project's description.

Basically, we clip (actually we use ellipsis if you're at HEAD) overly long titles. If you make a dashboard and put content heavy items in a the narrow column on a very narrow screen, this is what can happen. We have alternate displays for tablet and mobile widths.

tab and enter both seem correct / commonly used in this UEX, at least from my limited testing of a few mail clients, gmail, facebook, etc.

I don't think expecting people to hit enter is entirely reasonable – I'm personally scared that it'll submit the form, which is what enter ordinarily does in a form (except in a textarea).

Oh! I didn't think of hitting enter (I'm used to tab-completing instead).

For me, focus goes to the next input, which seems correct. That is:

Closed by commit rPfa77fdd168d4.

For mixed-language data, surely collating in the user's locale is preferable to collating in the default locale for the install? An example of this type of data is user "Real Names", which show up when trying to typeahead users, but contain letters from different languages with some frequency. This specific type of data is present to some degree on most installs, but there's no single valid language for it, since user human names are written in a variety of languages.

I want the strings to collate as the user expects strings in their language to collate, even if the strings are not actually written in their language. This will produce the best result if the strings are written in their language, and a reasonable (consistent with expectations) result if the strings are written in some other language or a mixture of languages.

I don't know if that assumption (that browser locale settings are reliable) actually is reasonable. T1888 documents a case where toLocaleDateString() did something a user found surprising/undesirable.

If you really want as-good-as-possibly locale-insensitive collation

Per T5403, I agree that pursuing richer results is probably something we should do first, since it would be better to give you the information you need to make this choice in the menu. I'm going to mark T3670 as blocking this since we'll need to reexamine some of the design there anyway, and I think that will also tend to make this choice easier by providing more context.

In T6465#82339, @chad wrote:

Our datasource typeaheads are all able to be called without javascript. For example, the repository typeahead (like in your Herald image) is here:

https://secure.phabricator.com/typeahead/class/DiffusionRepositoryDatasource/

Or as JSON:

https://secure.phabricator.com/typeahead/class/DiffusionRepositoryDatasource/?__ajax__=true

I don't know if @epriestley has other thoughts, but sounds suspiciously like your webserver is sending the incorrect JS files, or old JS files (either by caching or other mechanic).

We don't even use getPreventDefault that I can find. https://github.com/phacility/phabricator/search?utf8=%E2%9C%93&q=getPreventDefault&type=Code

Nop, versions are

Are you using Beta browsers?

We have two errors while inspecting the element. Checking on this

Ok, we shall check this.

Our datasource typeaheads are all able to be called without javascript. For example, the repository typeahead (like in your Herald image) is here:

Ok, Chad. We shall continue to figure it out. Thanks for your support.

Unfortunately, we cannot reproduce this and have no other reports right now. Happy to leave this open, but we don't have any additional thoughts. See https://secure.phabricator.com/book/phabricator/article/feedback/#unreproducible-problems for more information.

Yes. Typeahead is coming with Maniphest and other tools. It was working prior to the up-gradation of phabricator installation on October 24 around 3 a.m EST.

and Herald is the only Typeahead you are having issues with?

Thank You,
*UNAIS A*
Cloud Engineer

Hi Chad,

I don't have any other ideas. I'd try the following:

Thanks for looking into this, Chad. I think this is not a browser issue. I am able to see the suggestions on a local installation using the same browser