Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node removal should not trigger "update the image data" #274

Open
yoavweiss opened this issue Dec 7, 2015 · 8 comments
Open

Node removal should not trigger "update the image data" #274

yoavweiss opened this issue Dec 7, 2015 · 8 comments

Comments

@yoavweiss
Copy link
Member

Following an IRC discussion I don't think that node removal should trigger the "update the image data" algorithm as it may trigger spurious downloads, and there's no real benefit in doing that.

Once the image is removed from the picture parent, nothing will be displayed. Also, once it will get added elsewhere, "update the image data" algorithm should run.

Maybe we should just make sure that once it was removed from picture, the algo should run at next insertion (even if not to a picture parent or a separate document)?

@yoavweiss
Copy link
Member Author

/cc @zcorpan

@zcorpan
Copy link

zcorpan commented Dec 7, 2015

It might not be displayed but it can be painted on a canvas and its naturalWidth etc can be read. I'm not convinced we should complicate this. Is it a problem in practice? The "relevant mutations" are intentionally pretty dumb to be more likely to be interoperable.

@yoavweiss
Copy link
Member Author

I'd argue that it's more likely that a subtle "removing <img> from one parent and adding it to another" will cause spurious downloads than it is that handling of a detached img node would result in the wrong image being displayed by accident.

@yoavweiss
Copy link
Member Author

More irc discussions lead to the conclusion that the above scenario won't trigger spurious downloads if done in the same script, but the "removed an <img> and forgot about it" would.

@yoavweiss
Copy link
Member Author

A way to resolve this would be to "update the image data" with a null "selected source" in the removal scenario.

@zcorpan
Copy link

zcorpan commented Dec 7, 2015

That would mean an extra flag to "update the image data", and check it in step 3 and 8. Step 9 would then set the image to the broken state and fire an error event. (Maybe we should avoid the error event also?)

@yoavweiss
Copy link
Member Author

Yeah, avoiding the error is probably better

@zcorpan
Copy link

zcorpan commented Dec 7, 2015

But that would still leave the image broken if you insert it to the document again... I'm still unconvinced we should change things here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants