When creating a screenshot the clickable link in chat doesn't work

Can you please have a look at the log and see if there are any errors or warnings?

This also occurs in 1.11.2.

EDIT: Yes it is an error.

[08:26:33] [Client thread/ERROR]: Couldn't open link: Failed to open file:/D:/Users/MyName/AppData/Roaming/.minecraft/screenshots/2017-05-21_08.26.30.png. Error message: A device attached to the system is not functioning.

[08:26:34] [Client thread/ERROR]: Couldn't open link: Failed to open file:/D:/Users/MyName/AppData/Roaming/.minecraft/screenshots/2017-05-21_08.26.30.png. Error message: A device attached to the system is not functioning.

Probably not working because your .minecraft is in the D:/ drive. Works fine with my brother and his .minecraft is in the C:/ drive.

The bug you are experiencing might be a different one, would be great if @unknown could confirm or deny that.

The following is based on a decompiled version of Minecraft 1.12 using MCP 9.40 pre-1.

Java automatically adds a dot at the end of the game directory path due to the java.io.File.getAbsolutePath() call which can return an absolute path which is also a canonical path, but also a path which is only absolute since a path can have multiple absolute paths. While this surely isn't the most elegant solution, one can easily get the ClickEvent to work by adding a one liner at the beginning of the net.minecraft.util.ScreenShotHelper.saveScreenshot() method.

Suggested fix

try
{
	// This line will check if the game directory path ends with a dot and removes it if it does.
	String fgamedir = gameDirectory.getAbsolutePath().charAt(gameDirectory.getAbsolutePath().length() -1) == '.' ? gameDirectory.getAbsolutePath().substring(0, gameDirectory.getAbsolutePath().length() - 1) : gameDirectory.getAbsolutePath();
	File file1 = new File(fgamedir, "screenshots");
	file1.mkdir();
	BufferedImage bufferedimage = createScreenshot(width, height, buffer);
	File file2;

	if (screenshotName == null)
	{
		file2 = getTimestampedPNGFileForDirectory(file1);
	}
	else
	{
		file2 = new File(file1, screenshotName);
	}

	ImageIO.write(bufferedimage, "png", file2);
	ITextComponent itextcomponent = new TextComponentString(file2.getName());
	itextcomponent.getStyle().setClickEvent(new ClickEvent(ClickEvent.Action.OPEN_FILE, file2.getAbsolutePath()));
	itextcomponent.getStyle().setUnderlined(Boolean.valueOf(true));
	return new TextComponentTranslation("screenshot.success", new Object[] {itextcomponent});
}
catch (Exception exception)
{
	LOGGER.warn("Couldn't save screenshot", (Throwable)exception);
	return new TextComponentTranslation("screenshot.failure", new Object[] {exception.getMessage()});
}

As I'm currently unsure what exactly causes this problem, it might be worth trying to reproduce this bug on other operating systems.

EDIT: As @unknown has already described here: MC-113208; a way simpler solution would be to use file2.getCanonicalPath() instad of file2.getAbsolutePath().

@@unknown it looks like you partwise describe MC-113208. We do not know what exact problem @unknown has / had and the message in @unknown comment looks different from the one the problem you are describing likely produces, probably "The system cannot find the file specified." like MC-113208.

It is great that you took the time to do a code analysis though. Are you sure that the case you are describing is really happening?

@unknown So, I just tried to reproduce this bug in different versions and different game directories and for some reason I could only get it to work in my MCP game directory. Every other game directory (.minecraft / even a test folder on my desktop with dots in its name) works just fine. I get the following console output from eclipse using MCP:

[Client thread/ERROR]: Couldn't open link: Failed to open file:/C:/Users/bemoty/Desktop/mcp940-pre1/jars/./screenshots/2017-07-11_23.48.25.png. Error message: The system cannot find the file specified.

While this is indeed a different error message than @@unknown received when trying to reproduce the bug, the message looks pretty much the same as the one in MC-113208. After carefully examining the code I'm pretty certain that it's the dot in the absolute path causing this to happen since every other manually inserted path seems to work. The problem described here is pretty surely related to MC-113208.