Photoshop: Script bug resize layer back document up one history state

  • 2
  • Problem
  • Updated 2 years ago
  • Acknowledged
  • (Edited)
Nasty scripting bug resizing layer for some unknown reason resize backs up a history state before resizing. I have tested this in CS5, CS6, CC and CC 2014 all fail the same way. Nasty Nasty...

I can program around that bug if history states are being recorded for the script. However I like to suspend history state recording in scripts so that its easy to back up in history after the script is used if need be.

However that bug can destroy the document and also remove prior history states in so that its impossible to recover the document from history for prior state has been replaced with the recording of the use of the script. How many states are removed would depend on how many .resize(); the script did. Nasty Nasty.

Here are some screen of the bug in action. The fist before and after look the way the script is designed to work. However I did an extra select all before using the script. You see its no longer in history in the after.

The second before and after same as first without the extra select all note a guide line has been removed.

In the third before and after I changer the order of my of steps before the script I first drag out the guides then place in the image. You see that the image has been removed the wrong layer has been resized and the place removed from history. Nasty Nasty.

The script works when history is not suspended for I programmed the script to work around the bug...
Photo of John McAssey

John McAssey

  • 191 Posts
  • 7 Reply Likes

Posted 4 years ago

  • 2
Photo of Jeffrey Tranberry

Jeffrey Tranberry, Sr. Product Manager, Digital Imaging

  • 13977 Posts
  • 1670 Reply Likes
Hi John,

Is it possible to get a copy of a script to reproduce?
Photo of John McAssey

John McAssey

  • 191 Posts
  • 7 Reply Likes
I did some more testing the resize() only back up one step in the history when history is suspended. I put a alert in before and after the resize so I could look at the history palette I only see the backup when history is suspended. When history is not suspended I see resize record

Save Selection
deselect
freetransform
load selection
delete channel

Those steps make sense to me. However it could be that resize also recorded an additional step used undo before the transform step restoring the saved selection and deleting the alpha channel it created with the save selection.. And that undo cause the history palette backup I see that cause the document to be incorrectly reverted and cause a layer to be deleted and the wrong layer to be resized.

Any undo or backing up in history when history is suspended would back up to some state before the history was suspended......
Photo of John McAssey

John McAssey

  • 191 Posts
  • 7 Reply Likes
So my educated guess is the first thing resize did was to do something like deselect note what was recorded in history the do and undo to recover a any removed selection. If what was recorded was deselect resize would save the selection, deselect, do the transform, restore the selection.

Here is a before and after resize with suspended history. You can clearly see the undo where the placed image was removed what surprises me is in the capture the active selection is still there. I know I was loosing that selection. However the display is not fully refreshed yet as you see the image is gone however the black smart object layer is not yet visible and neither is the background layer.
Photo of John McAssey

John McAssey

  • 191 Posts
  • 7 Reply Likes
This means the undo done should not have been done. So I tested what would happened if there was no active selection when the script did the resize. So I added a deselect into the script before the resize. and left the added select after the resize in.

That test showed the script works correctly either way history suspended and with history being recorded.

Link to script with the work around coded in. http://www.mouseprints.net/old/dpr/Fi...

So I can code around the bug. Does that mean this will be one more bug the Adobe does not fix?
Photo of Jeffrey Tranberry

Jeffrey Tranberry, Sr. Product Manager, Digital Imaging

  • 13977 Posts
  • 1670 Reply Likes
Hi John,

Sounds like QE can repro the behavior. Going to have engineering take a look.
Photo of John McAssey

John McAssey

  • 191 Posts
  • 7 Reply Likes
Still a problem in CC 2015
Photo of John McAssey

John McAssey

  • 191 Posts
  • 7 Reply Likes
This bug now crashes scripts in CC 2014 and CC 2015. Photoshop CC 2014 loops an peg a processor for a long time before it crashes. The Photoshop CC 2051 also loops but crashes sooner then CC 2014.