#42018 closed defect (bug) (fixed)
Can't Edit Image in RTL/Hebrew version of WordPress
Reported by: | rivkasa | Owned by: | iseulde |
---|---|---|---|
Milestone: | 4.9 | Priority: | high |
Severity: | major | Version: | 4.8.2 |
Component: | TinyMCE | Keywords: | needs-patch |
Focuses: | rtl | Cc: |
Description
After inserting image into editor, the Edit image toolbar flickers and it's buttons can't be pressed
Attachments (2)
Change History (30)
#1
@
7 years ago
- Focuses rtl added
- Summary changed from Can't Edit Image in RTL/Hebrew version of Wordpress to Can't Edit Image in RTL/Hebrew version of WordPress
#2
@
7 years ago
Hi @rivkasa - thanks for your bug report and welcome to trac.
i was able to reproduce this issue in Chrome Dev. Can you confirm the browser/version OS you are on? I did not see the issue in Firefox.
#3
@
7 years ago
Chrome seems to be firing a 'scrollwindow' event when the toolbar is displayed, causing it to hide again, creating the loop.
42018.diff removes the listener and this fixes the issue in chrome, however i think this is a browser bug, not a wp bug.
#4
follow-up:
↓ 6
@
7 years ago
- Component changed from Editor to TinyMCE
- Keywords needs-patch added
- Milestone changed from Awaiting Review to 4.9
- Priority changed from normal to high
- Severity changed from normal to major
Confirmed in Chrome version 61.0.3163.100 (Official Build) (64-bit). Yeah, looks like a browser bug: it erroneously fires scrollwindow
on mouse move when the cursor is over the toolbar buttons, only in RTL mode (there is no actual scrolling). This may be CSS/styling related. The same happens when the image toolbar is shown and the cursor hovers over the buttons in the main toolbar.
Don't think it is a good idea to remove hiding of the toolbar on scrolling. This will leave it "hanging" in place after the user has scrolled the editor and the image is no longer visible. Perhaps only as a last resort and only in Chrome in RTL mode.
#5
@
7 years ago
Caused by showing the .mce-tooltip
div (that is appended at the end of the body) and setting left: [value]px
on it from JS at the same time. Don't seem to find a CSS based workaround for this, seems Chrome shows the div before applying the styles to it, so the window height is changed despite that the div is with position: absolute;
. Looking for another workaround.
#6
in reply to:
↑ 4
;
follow-up:
↓ 8
@
7 years ago
Don't think it is a good idea to remove hiding of the toolbar on scrolling. This will leave it "hanging" in place after the user has scrolled the editor and the image is no longer visible. Perhaps only as a last resort and only in Chrome in RTL mode.
Absolutely agree, I only uploaded the patch to demonstrate the issue. Wonder if this is a known issue or something that should get fixed upstream? seems hacky: maybe remove the scroll listener before showing the div, then re-add it?
#7
@
7 years ago
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In 41643:
#8
in reply to:
↑ 6
@
7 years ago
Replying to adamsilverstein:
uploaded the patch to demonstrate the issue
Yeah, figured it.
Seeing some general slowness when the tooltips are shown, even they fail sometimes. There's definitely "something" going on in Chrome...
#9
@
7 years ago
Thanks so much for taking care of this issue. It's been bugging many Hebrew speaking users. I've been seeing posts about it in WordPress Development Facebook groups in Hebrew, and some people (myself included) have reported it in the forums: here and here.
Just out of curiosity, do you know why it happens only in RTL?
#10
@
7 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Hi
I am still experiencing this bug.
This happens also with the add link/link editor tooltip.
I am using this version of chrome:
Version 62.0.3202.75 (Official Build) (64-bit)
Is there a way to solve this in the meantime?
Dan
#11
@
7 years ago
- Owner changed from azaozz to iseulde
- Status changed from reopened to assigned
Given @azaozz being on sabbatical, @iseulde can you provide support here?
#12
follow-up:
↓ 13
@
7 years ago
@danstramer Did you test this with trunk, or with the latest WordPress version 3.8?
#13
in reply to:
↑ 12
@
7 years ago
Tested with WP 4.8.2
Replying to iseulde:
@danstramer Did you test this with trunk, or with the latest WordPress version 3.8?
#14
follow-ups:
↓ 15
↓ 16
@
7 years ago
- Resolution set to fixed
- Status changed from assigned to closed
@danstramer This issue appears fixed in trunk and should be corrected in the next release - 4.9, currently planned for November 14th - https://make.wordpress.org/core/4-9/. If you want to help, you can test this fix with the Beta Testers plugin - https://wordpress.org/plugins/wordpress-beta-tester/.
Thanks!
#15
in reply to:
↑ 14
@
7 years ago
Thanks @adamsilverstein,
Is there an option to override a file with the fix before November 14th?
Replying to adamsilverstein:
@danstramer This issue appears fixed in trunk and should be corrected in the next release - 4.9, currently planned for November 14th - https://make.wordpress.org/core/4-9/. If you want to help, you can test this fix with the Beta Testers plugin - https://wordpress.org/plugins/wordpress-beta-tester/.
Thanks!
#16
in reply to:
↑ 14
;
follow-up:
↓ 19
@
7 years ago
Thanks @adamsilverstein,
Is there an option to override a file with the fix before November 14th?
Replying to adamsilverstein:
@danstramer This issue appears fixed in trunk and should be corrected in the next release - 4.9, currently planned for November 14th - https://make.wordpress.org/core/4-9/. If you want to help, you can test this fix with the Beta Testers plugin - https://wordpress.org/plugins/wordpress-beta-tester/.
Thanks!
#19
in reply to:
↑ 16
;
follow-up:
↓ 20
@
7 years ago
Is there an option to override a file with the fix before November 14th?
@danstramer the easiest way would be to install and run the beta tester's plugin. Please let us know if this fixes your issue!
#20
in reply to:
↑ 19
;
follow-up:
↓ 21
@
7 years ago
Thanks.
Will this be ok on a production site?
Replying to adamsilverstein:
Is there an option to override a file with the fix before November 14th?
@danstramer the easiest way would be to install and run the beta tester's plugin. Please let us know if this fixes your issue!
#21
in reply to:
↑ 20
@
7 years ago
Replying to danstramer:
Thanks.
Will this be ok on a production site?
I would say no! It is beta software :) Safer to wait for the next release.
Maybe you can work around the issue using the editor text mode or switch your interface into english? Sorry, I know that isn't a great solution!
#22
@
7 years ago
There are ways to open the editing link and image windows even in Chrome. I collected them and wrote them | on the forum, but I'll list them here too:
Regarding links:
- Inserting: Just paste the link on the text you want the link to be. WordPress will turn the text into a link, without having to use the hovering toolbar at all
- Editing: After clicking the link the toolbar appears. In order to get to the gear button tab twice, and then press the Enter button – that will open the link editing window.
Regarding Images:
- Editing and Aligning: After clicking the image the toolbar appears. Click the desired button *a long click*, and the window will open or the image will be aligned as desired.
#23
follow-up:
↓ 25
@
7 years ago
@adamsilverstein, How about applying the patch, could that also be a recommended solution in the meantime?
#24
@
7 years ago
Thanks @leac, thanks @adamsilverstein.
Having 40 Hebrew client sites that all have this issue is a real problem.
I would apply a patch in the meantime till the 4.9 update, but this current situation is not something that I can tell my clients: "wait a couple of weeks till it's fixed"
What would be the quickest wait till 4.9?
IS there a guide as to which files I can override with the corrected code?
Thanks again,
Dan
Screenshot