[PAGES-126] Magnolia Pages App editing capabilities lost on latest Firefox 52 / Chrome 57 on hybrid devices Created: 17/Mar/17 Updated: 11/May/17 Resolved: 31/Mar/17 |
|
| Status: | Closed |
| Project: | Magnolia pages module |
| Component/s: | None |
| Affects Version/s: | 5.4.7 |
| Fix Version/s: | 5.5.4 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Fadi Wissa | Assignee: | Federico Grilli |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | browser_issue, chrome, firefox, page-editor, pages-app | ||
| Remaining Estimate: | 0d | ||
| Time Spent: | 5d | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Various users on Windows 7 & Windows 10 using the following browser versions (working fine on Macs): Chrome: 57.0.2987.110 (64-bit) / 56.0.2924.87/ 56.0.2924.87 (64-bit) |
||
| Attachments: |
|
||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||||||||||||||||||
| Release notes required: |
Yes
|
||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||
| Sprint: | Basel 88, Basel 89, Basel 90 | ||||||||||||||||||||||||||||||||
| Story Points: | 8 | ||||||||||||||||||||||||||||||||
| Description |
|
Multiple clients have reported in parallel that after their web browsers were updated over the past week or so Magnolia page editing functionality was lost. Such users are on Windows and on latest Firefox 52 and Chrome 57 and using Magnolia 5.3.5 or 5.4.7 pro STK (and 5.5.2 demoauthor as mentioned below). They cannot see the action bar (as per screenshots below). For others, they could see the action bar but could not select actual page areas/components to edit. We performed such tests on clean bundles of 5.3.5 and 5.4.7 pro STK which are the two standard versions we implement/support with our clients. Unfortunately even testing on Magnolia's demo author (currently on 5.5.2) it doesn't work (https://demoauthor.magnolia-cms.com) - on one browser it doesn't load the action bar, on the other it loads it but you cannot edit page areas. Investigation and possible solution: The issue can actually be reproduced (simulated) e.g. on a MacBook Pro by
The solution consists in enabling mouse selection listener even when touch support is enabled cause that is the case for hybrid devices. |
| Comments |
| Comment by Bradley Andersen [ 20/Mar/17 ] |
|
Confirmed on latest Chrome Browser on AR W10 machine: From a different machine (Mac OS X latest), was able to edit the page created on the W10 machine. |
| Comment by Fadi Wissa [ 20/Mar/17 ] |
|
Thanks for checking @Bradley |
| Comment by Fadi Wissa [ 21/Mar/17 ] |
|
Apologies for the duplicate comment - I'm not sure whether I should follow up here or via MGNLUI-3846 This issue is affecting multiple clients' ability to manage their portals - we would appreciate your feedback regarding when a resolution is planned for. Thanks for your support |
| Comment by Federico Grilli [ 21/Mar/17 ] |
|
Hello, I tried to reproduce the issue but all seems to be fine on current demo, at least.
Magnolia:
Browsers:
What I did:
Results:
|
| Comment by Fadi Wissa [ 21/Mar/17 ] |
|
Multiple clients and some our employees, in addition to Bradley have been able to reproduce this issue. I can launch a Windows server (AWS Workspace) that has it broken and share credentials - would this help? |
| Comment by Michael Mühlebach [ 21/Mar/17 ] |
|
fgrilli Please try on our W10 machine as well in Abby Road. bandersen was able to reproduce it there. |
| Comment by Federico Grilli [ 21/Mar/17 ] |
|
fwasi thanks, as Michael suggested, I'll first try on another windows box we have here in the office. That would also help us debug/fix the issue cause there likely are javascript errors produced by the page editor's widgetset. |
| Comment by Fadi Wissa [ 21/Mar/17 ] |
|
Thanks Federico - once this is confirmed, would you please give us more insight into which Magnolia versions fixes would be released for? |
| Comment by Federico Grilli [ 21/Mar/17 ] |
|
Okay, I was able to reproduce the issue on our Win10 box. Unfortunately there are no javascript errors, only a couple of warnings about using deprecated jQuery methods. I'm now comparing the page sources produced by FF, Chrome and IE (working) to see if there's some noticeable difference. |
| Comment by Federico Grilli [ 21/Mar/17 ] |
|
fwasi you're welcome. The issue has been marked as a blocker so it has highest priority. The version relevant for you should be 5.4.12 which should be out rather soon but cannot say when exactly. Maybe mmuehlebach can chime in at that regard. |
| Comment by Fadi Wissa [ 21/Mar/17 ] |
|
Thank you Federico - this is good news for us. |
| Comment by Federico Grilli [ 23/Mar/17 ] |
|
UPDATE: After some investigation, the issue seems to be caused by latest Chrome or FF + touch screen support on Windows10. If disabled, as explained here http://www.thewindowsclub.com/disable-touch-screen-windows-10, page editor works just fine on both browsers. That would also explain why the issue did not show up on the Win10 VMs I tried or on the Win7 laptop. |
| Comment by Fadi Wissa [ 23/Mar/17 ] |
|
Thanks for the update Federico. I tried the above explanation on a Windows server I have access to that has the page editor broken (as per screenshot), and I do not even have the option of disabling such "Touch Screen Support" |
| Comment by Federico Grilli [ 23/Mar/17 ] |
|
Hello Fadi, that's weird. So far I have seen the issue only on Windows10 OS with touch screen support enabled. What Windows OS is the one in the screenshot? |
| Comment by Fadi Wissa [ 23/Mar/17 ] |
|
Federico - this screenshot is from this Server machine: I'll ask a colleague who has it broken on their laptop to check the resolution suggested above and get back to you shortly. |
| Comment by Fadi Wissa [ 24/Mar/17 ] |
|
Federico - after LOTS of attempts to disable touch on the Win server I am testing on, I followed the following steps on Firefox 52.0.1 Navigate to: about:config ... and it worked Which confirms the behavior you detected earlier and that touch detection on Windows devices is the root cause of the issue. I look forward to hearing whether you have any suggestions for more user-friendly resolutions to the issue. (by the way I used the following basic JSFiddle to detect whether Firefox was treating my page as touch enabled or not: http://jsfiddle.net/robreact/uqodo7aw/1/ - shows "false" if touch disabled and "true" if touch enabled - and Pages App only worked with touch disabled of course as per above... ) And the same "fix" worked on Chrome 57 by setting the "Touch Events API" flag to "disabled" under chrome://flags: |
| Comment by Federico Grilli [ 24/Mar/17 ] |
|
Hello Fadi, cool and thanks a lot for your investigations! I actually tried the disabling "Touch Events API" trick on Chrome but for some reason it didn't work for me. Will try again. Code-wise, after debugging Magnolia's client code I could not pinpoint any evident cause for this malfunctioning. |
| Comment by Fadi Wissa [ 24/Mar/17 ] |
|
Disabling "Touch Events API" worked for me (to restore page editing functionality) on the Windows Server 2016 machine I used. |
| Comment by Federico Grilli [ 24/Mar/17 ] |
|
Update: thanks to a co-worker's suggestion we found the place in Magnolia code where we may handle this. PR coming soon |
| Comment by Federico Grilli [ 28/Mar/17 ] |
|
Blocked as it can be merged only after 5.5.3 release |
| Comment by Richard Gange [ 29/Mar/17 ] |
|
Customer needs this on 5.4 |
| Comment by Nicole Stutz [ 03/May/17 ] |
|
Hi there, we make the same experience (<5.5) Anyway, just this information for FF (Windows 10): disable=(0) enable=(1) auto-detect=(2) (https://developer.mozilla.org/en-US/docs/Web/API/Touch_events). disabled worked for us: about:config and setting dom.w3c_touch_events.enabled=0 |
| Comment by Federico Grilli [ 04/May/17 ] |
|
Hi Nicole, that actually does the trick but in about one week you'll be to get rid of the workaround with the 5.5.4 release (or you can already if you're on 5.4.x by upgrading to 5.4.12). |
| Comment by Nicole Stutz [ 11/May/17 ] |
|
Hi Federico, Thank you! |