My apologies! I looked at that menu and somehow totally missed it.

The monospaced text also overflows:

I thought that this might be closed as a duplicate... Although I think that adding "File" to the quick create menu might be a quick win here... Is there any specific objection to this?

Click the Mobile Menu, then Members.

I don't think there's anything reasonable we can do here.

Ran into it again, (on this install)

Should be resolved, probably.

Presume fixed since you don't to scroll left/right anymore.

The feature basically changes the User Agent to desktop Chrome as far as I know, and nothing more. That's why Phabricator doesn't appear any different, because the CSS is already optimized for mobile based on actual screen size (and not redirecting based on user agent).

I think their premise is sound in general, since sites sometimes display full alternate sites (I hate when my wife links me mobile URLs and I'm on a desktop). But we serve the full site with just different CSS, so nothing should be missing.

The only time I ever tried to use this was when the project sidebar wasn't available / usable on mobile and I had no way of creating a workboard.

I was just curious as to what it would do... I'm happy for this to be closed as "Wontfix".

Are you using this or just testing? In practice, I don't want to support this.

Just tested it again with a touchpad (laptop), and it still works.

Definitely desirable, although some of them (releeph, oauth server, arcanist project edit) might be tricky to test.

There is a manageable number of buildStandardPage callsites, might be easy to remove if there is only 1-2 missing features.

Typically I'd just switch this over to buildApplicationPage and call it a day, but I don't think that works with frame.

I think we can put the frame logic in buildApplicationPage(), and then switch to it. I can tackle that if you aren't sure how to not break stuff.

buildApplicationPage() calls setDeviceReady(true) on the $page, buildStandardPage() does not.

I'm not sure how best to proceed here. What's the difference with buildApplicationPage and buildStandardPage when it comes to device?

Removing $is_framed will break the DarkConsole "XHProf" tab, which loads the profile in an <iframe />.

hmmm maybe this is buildStandardPage thing.

Oh, on an actual mobile device. We should remove that JS check now, I think it's safe globally.

I assume you mean the table? That is our mobile display for tables (scrollable).

Are you on a laptop? Seems touch specific.

Not quite, see https://secure.phabricator.com/xhprof/profile/PHID-FILE-i37p3oetbxkqjt2fs35h/.

works for me on Windows/Chrome 41. Just to make it more annoying, I guess.

Well this now repros in plain Mac/Chrome v41. Help me 1-up diff view, you're my only hope!

Seems working fine now on mobile.

I have a Droid MAXX and see this sort of thing sometimes as well. It usually clears up on a reload of the page.

I see this on secure.phabricator.com and local installs.

It would also be useful to know if this is a secure.phabricator.com issue or you see it on your local installs as well.

Next time people see it, it would be nice to confirm suspicions that JavaScript isn't running (toggle a menu or something?)

It seems to happens if JavaScript doesn't download / execute, which breaks lots of things (besides layout). Unclear why though or how to reproduce with consistency (perhaps even a CDN issue?). I've only seen it maybe 1/1000 page loads.

I almost merged them when they popped up. :P

OIC, I am confusing XPHAST and XHPROF tasks, I'm a bit jetlagged it seems. Didn't notice two different tasks here.

Haha, well you know me and killing apps. Always a fan. :-)

This stretches the bounds of imagination, but I can come up with a use: although we do only a tiny amount of this today, a possible use case is that we may take a different server-side rendering pathway for mobile agents than we do for desktop agents in the future. This does technically happen today, but the amount of code involved is tiny, and is unlikely to ever affect a profile.

@joshuaspence my assumption is exactly 0 people use this tool on mobile, And maybe 5 use it on desktop.

Definitely low priority, but why not?

Yes. My clever plan is to wait for mobile devices to have an effective resolution of 3600x8200 and MindMouse technology.

after the IPO

I'll show you! I'll make this the greatest mobile app the world has ever seen!

Yea, there are just certain things you can't make mobile friendly, I think this may be one of them.

This is "working as intended" on mobile. We should maybe mark XHPAST as developer/prototype or something.

I can't imagine someone using this on mobile, is there a need for it o can't think of?

I am not sure which project this goes into.

Loaded up my Nexus for 4 for testing, Android 4.4.4 with Chrome 35, not reproducible. Updated to latest (40) and it reproduces.

I can't reproduce this on iOS.

I don't think this is new, it's worked like this for some time, not sure if its "more sensitive" with the changes or not, but that area has always been sub-optimal until we get 1-up diffs.

It looks like you started scrolling left/right in the diff area. If your finger is on that area, it's more sensitive to where your scrolling since it can be left/right/up/down.

Hah, well at least Chrome on iOS doesn't seem to have this behavior. Strange that iOS is better than Android though for Chrome. Is it a current version?

Serializing into a hidden field sounds like the correct approach to me.

Native fields (text, textarea) work fine; tokenizers exhibit this behavior because (some hand-waving here) we aren't writing their values to a real input, sort of, probably. Blah blah bfcache browsers etc etc.

In T7029#92850, @epriestley wrote:

You can reproduce this in a normal web browser (at least, in Safari):

• Click "Edit Task" on any task.
• Add a project to the "Projects" field.
• Type some text in the "Description" field.
• Click a link on the page, like the Phabricator logo.
• Press the browser back button.

The description change persists, but the field change does not.

This is probably fixable, but also probably involves some stupid garbage nonsense where we serialize tokens into a hidden field value.

Actually, it seems that the subscribers field doesn't persist either (I originally thought that it did, but it seems that only the default subscriber of myself persists). So yeah, this may not be fixable.

You can reproduce this in a normal web browser (at least, in Safari):

Seeing as the other fields persist, I suspect that it should be fixable.

Do you feel this is fixable by Phabricator?

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