We don't currently have plans on integration, when/if we do it'll be done in a more overly-engineered way to support many different file type and plug-ins.

We don't have plans to support this. In general features that serve very small or just a single install are not likely to be pursued. Please see https://secure.phabricator.com/book/phabcontrib/article/feature_requests/ for more information.

ambitious

It looks like his headers match our if else statement when cacheable isn't set (date, etc). It looks like developer mode could trigger that, but I can't repro in my sandbox.

We set these headers explicitly here:

In general I think setting these aggressively (like +1 month) should be fine. For static resources like css/js we bundle them with a hash so you won't have old bundles when you upgrade Phabricator.

Light grepping the source, I don't see us setting these headers in PHP. I'd check your server settings, it looks like nginx default is off. I'm not sure how this install is configured, maybe @epriestley knows.

@chad it must be a misconfiguration somewhere on our end... i see both a "no cache" header and a past date for "expires":

When I have an image with an expiration in the past, it does cause us to reload the image each keystroke. I just can't replicate the issue with stock Phabricator.

My only thoughts are something server side (http) is causing the image to not cache in your browser? What do the response headers look like? Is the expiration in the future or past?

@chad i tried before and couldn't...

Does it reproduce on this install for you @shadowhand?

@epriestley sorry it took a while to follow up on this, but it's still happening after the upgrade.

Sorry, came up with better search terms and found the canonical issue.

This is expected -- in theory, each inline should be individually editable (with viewable history), removable, quotable, and show raw-able. There's just no UI for this (and not much of a clear place to put it in some cases). The underlying requests likely work correctly today, since inlines and normal comments are identical from the backend's perspective.

Is that true even if you make a new mock with new comments (i.e., everything created after the upgrade)? We fixed several file permissions issues in the relatively recent past, but they are partially state-based and older files may not have the correct state.

After upgrading to the latest version of code, I am still seeing the exact same behavior: when making an comment, the inline comment images are reloaded and are not cached:

I will update our local instance and see if the issue goes away. And FWIW, I'm not on dialup, but rather a 3G tether.

@epriestley that's from Chrome Devtools (Network pane). They are definitely network requests and not cache. There would be a (from cache) and color change on the line item if it was cached.

(I'm using Charles, FWIW.)

Also, I'm not sure what tool you're screenshotting, but are those definitely network requests (vs fills from local cache)? Are you visually seeing the images load, or just seeing these requests in a log and concerned about unnecessary bandwidth use?

And those are against M54, which has several images.

Hmm, I can't repro in Chrome either. Does it repro on this install?

My assumption is Pholio's inline comments contain large images, and Differentials mostly just contain text. We might get Differential for free with this task, I'm not up to speed on that code to know.

@epriestley perhaps it only reloads when there are multiple images on a mock? I was not able to reproduce with a mock that only has one image and no revisions. Commenting on a mock that has multiple images and multiple revisions resulted in this (using Chrome):

It's way simpler to just reload everything, and the amount of bandwidth in the comment text is trivial, so we're unlikely to change that. It would only be impactful if you had a dialup connection or something.

Okay, so T1895 is somewhat related, but not completely. I fail to see how this is strictly about Pholio though, as the exact same problematic behavior (refreshing inline comments) can be seen in Differential.

I have triaged this into two different tasks. First is T1895 which covers all preview fields in Phabricator. Then this task, to be more specific about Pholio and even if preview is on, not re-fetching the images/comments.

It's not just Philio, but also Differential.

I merged T4101 here because our current evaluation (see D9570) is that the browser fullscreen APIs still have a lot of issues and undesirable behavior, and we're unlikely to pursue them in any application until browser support improves.

◀ Merged tasks: T4101.

I'm going to close this since we no longer scale based on the vertical window height and now allocate far more space for images, and from what we've seen/heard the new version works much better. If you're still hitting issues, feel free to file a task based on how you'd like the new UI adjusted.