-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Render each mime-part into an individual iframe #9519
base: master
Are you sure you want to change the base?
Conversation
ba35bc4
to
2804d9d
Compare
2804d9d
to
d6a17b3
Compare
d6a17b3
to
b3ff9c8
Compare
3a8353c
to
edf0cc8
Compare
@alecpl I didn't find any problems, but still want to check some more plugins. Also one test is missing. But I think the general approach won't change anymore, so a review would already make sense. |
@alecpl Do you think we should keep "larry" working for future releases? I'm not sure yet how much work it would be to make larry fit for this change, but before I even try I want to be sure that you consider it necessary. (I would deprecate it and keep it maintained for v1.6.x, but not later versions.) |
7e519b5
to
0f5f90d
Compare
I'm finished with cleaning the commit history now. |
This allows for a little cleaner code
This probably wasn't implemented previously because HTML-parts usually didn't run through get.php.
That way it's testable.
Meta refresh would require unsafe-inline in a CSP, which we want to avoid.
0f5f90d
to
3d8b8d3
Compare
(Rebased to latest of "master".) |
@alecpl Could you give me your opinion on this? Please also review the code. |
@alecpl Could you please let me know why you don't react on this PR? Are there technical concerns? Or just a lack of time? Or something different? |
I'm sorry. It's a lack of time amplified by the significance of this change. |
Would it maybe help to have renown community members review this to give a better standing ground and ease the burden? |
If you're concerned about the implications for existing plugins or other code that would be hard to adapt: How about we decide to go forward with breaking or structural changes targeting versions 2.x, and at the same time commit to maintaining a version 1.x by providing bug fixes (and maybe relevant improvements) without an EOL? |
This is exactly the plan, we do not backport new features (with a few exceptions) into old version branches. So, I'm not afraid of breaking stable versions. I'm afraid of supporting them being much harder with architectural changes like this. And I don't see that to be the main concern anyway. I need more time for this PR. This one is the hardest one. It's not about the code quality of the PR nor the idea itself. There are obvious pros, but there are also cons. |
Implementing #9465
TODO: