Problem/Motivation
During a large refactor/improvements about JS ImageWidgetCrop integration we have introduce a small bug during the initialization of Cropper. When you define crop area in "ADD" context AND Image Widget Crop widget configuration "Always expand crop area" set to "YES" If "NO" all works well.
Step to reproduce :
- Install fresh Drupal instance
- Enable image_widget_crop_examples
- Create a node of type "Crop simple example".
- Add a file in the image field
- Crop your picture
- Save the node
- You are redirected to the node view and the cropped zone isn't correct
- Edit the node
- The crop's default position is wrong and always positionned at the Top Left corner of the image with always the same dimensions but always in good aspect ratio.
- Change your crop area in editing mode
- Save the node
- You are redirected to the node view page again but your cropped image is good
- Click to "edit" to see that the default crop area position and dimensions are good too
This VIDEO can help to seen the problem.
I suppose the problem is in the initializeCropper function
// If "Show default crop" is checked apply default crop.
if (this.showDefaultCrop) {
// All data returned by cropper plugin multiple with delta in order to get
// proper crop sizes for original image.
this.setValue(this.$image.cropper('getData'), this.naturalDelta);
this.$wrapper.trigger('summaryUpdated');
}
EDIT : I admit my bad of that analize *_* This part aren't lie to show_crop_area option but to show_default_crop option to display a crop area automatically when the element is visible ...
I purpose you a more complete Feedback in this other VIDEO (This describe this bug + another bug but good to view where are based my tests).
Proposed resolution
Fix the bug with initialization with "show_default_crop" activated.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 2862709_edit_pass.png | 275.72 KB | duaelfr |
| #18 | 2862709_view_pass.png | 71.81 KB | duaelfr |
| #18 | 2862709_edit_fail.png | 268.24 KB | duaelfr |
| #18 | 2862709_view_fail.png | 37.69 KB | duaelfr |
| #15 | interdiff-2862709-14-15.txt | 1.3 KB | markhalliwell |
Comments
Comment #2
markhalliwellThe delta modification needs work. I'll try to take a look at this in more depth when I have time (likely this weekend again).
Comment #3
woprrr commentedAfter more improvements/Tests, I finally found the real problem ahead this bug :D !! Infact this problem appear when user enable the option "show_crop_area" (Always expand crop area)... When this option we have an error on InitializeCropper. This reduce drasticaly the futur fix :D
Comment #4
woprrr commentedComment #5
woprrr commentedComment #6
woprrr commentedHi @markcarver,
I need your specialist opinion about my analysis of that bug... I suppose that is not due to refactor because with the new approach we seems to be verry linked with Drupal events to initialize/destroy objects. But with these option we "enforce" the detail element to "open" with element attribute like :
It's possible to that method aren't compatible with our more precise approach and our js for wathever reason not are corretly initialized because the element are suppose to be hidden ? I think we can try to send data-attributes like others configuration to Js ImageWidgetCrop object and open details element with even appropried (I'm not sure with that...).
Edit : I can confirm if we comment "'#open' => $element['#show_crop_area']," All works good ... We will try to found another solution to open this details element.
Comment #7
woprrr commentedAfter more effort to understand, I think this is it
When we are on Add context and details element set to open, We never match with "value = visible" case. That can be usefull to understand it ?Edit : To help more I past another screenshot with that :
To try compare add context and edit context but nothing seems different *_* I don't understand why my last track are wrong again ;'(
Comment #8
woprrr commentedComment #9
woprrr commented@markcarver Do youi have an idea of this problem ? (I admit I didn't found solutions to avoid this problem) The better I can do is add more describe of problems and analize to help you :( sorry.
Comment #10
markhalliwell@woprrr, TBH, I really haven't looked at this issue yet.
I've been bogged down with work, sorry. I'll try to take a look soon-ish.
Comment #11
Scott Robertson commented@woprrr I think you're on the right track with the
pollVisibilityfunction. Havingvaluebe set tonullwill cause an event to be triggered the first time that function is invoked, although I'm not sure that it's actually causing this issue. However, I also noticed that the jQuery.is(':visible')check seemed quite unreliable for me. As in,visiblewould betrue, even though the image wasn't actually visible yet.Can you try replacing the pollVisibility function with the following and see if this issue goes away for you?
After I made the above changes, I could no longer reproduce this issue. If it works for you too then I can submit a PR.
Comment #12
markhalliwellYes, I keep forgetting that
:visiblehas its limitations.The solution in #11 is partially correct, but on the right track.
I'd rather we implement http://stackoverflow.com/a/15203639/1226717 as it's a little more comprehensive.
Comment #13
Scott Robertson commented@markcarver Good idea. I came across that exact question, but missed the answer you linked to and only tried to implement the answer that tested if the element was simply in the viewport, not actually visible on the screen, which of course didn't work very well. I'll try implementing that solution instead and test it out.
Comment #14
markhalliwellHere's a patch.
Comment #15
markhalliwellTypo and a minor optimization.
Comment #16
woprrr commentedHi guys,
I'm glad to see you in that issue :) !! I was read all comments and learn a lot thank you ! :) Now I understand more the problem and the limitation of is_visible :)
@markcarver I have tested all cases possible and WORKS !!!! GOD :) all work like a charm :) THANKS to you guys !
Comment #17
duaelfrI did manual testing on simplytest.
Without the patch : https://dcfd7.ply.st/node/1
With the patch : https://dcfdb.ply.st/node/3
Congrats!
(I updated the IS to make the steps more understandable)
Comment #18
duaelfrYou might enjoy some screenshots soo ;)
Comment #20
woprrr commentedMerged in 8.x.2-x :) We are ready to stable release now.