[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)
FireFox: Version 52 doesn’t work on any Windows computer


Attachments: PNG File Cannot disable touch screen support as suggested.png     PNG File Disable touch in Chrome 57.png     PNG File FF 52.0.1 on Win Server.png     PNG File Firefox 52.0.1 config change.png     PNG File Working on FF 52.0.1 after disabling touch via FF config page.png     PNG File broken on demo author as well.png     PNG File image-2017-03-17-23-42-33-316.png     PNG File image-2017-03-17-23-43-04-309.png    
Issue Links:
Cloners
is cloned by MGNLUI-4177 Pages app editing capabilities lost o... Closed
is cloned by PAGES-129 Magnolia Pages App editing capabiliti... Closed
Relates
relates to MGNLUI-3846 Edit bars and actions are missing in ... Closed
duplicate
is duplicated by MGNLUI-3832 Page Editor iframe sized incorrectly ... Closed
is duplicated by MGNLUI-3678 No component edit bars (Chrome, hybri... Closed
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 had been originally reported on Windows (with touch support) but can be reproduced on any hybrid device supporting both touch screen and mouse support. It has manifested on latest chrome and FF probably due to the fact that since their latest release those browsers support Touch Events API automatically, whereas in prior releases it was disabled by default.

The issue can actually be reproduced (simulated) e.g. on a MacBook Pro by

  • chrome: opening a tab chrome://flags and enabling Touch Events API
  • FF: opening a tab about:config and setting dom.w3c_touch_events.enabled=1 (0=automatic, 2=disabled)

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:
Created a new page on demo author on W10 machine - was able to add component (editor bars exist)
Then tried to edit that page, no edit bars exist.

From a different machine (Mac OS X latest), was able to edit the page created on the W10 machine.
Visited again the W10 machine, saw changes from Mac, but again was unable to edit.

Comment by Fadi Wissa [ 20/Mar/17 ]

Thanks for checking @Bradley
Yes, seems to be working fine on latest OSX - issue is always reported on Windows 7 & 10 with latest Chrome & Firefox

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
Fadi, gateB

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.
OS:

  • Windows 10 (on VirtualBox)
  • Windows7 (actual Win7 installed on laptop)

Magnolia:

  • 5.5.2 EE at demo.magnolia-cms.com

Browsers:

  • FF 52.0.1
  • Chrome 56.0.2924.87

What I did:

  • created new page. Added/edited/removed components.
  • edited existing page. Added/edited/removed components.

Results:

  • Page editor seems to be working fine.
Comment by Fadi Wissa [ 21/Mar/17 ]

Multiple clients and some our employees, in addition to Bradley have been able to reproduce this issue.
So I guess we just need to pin down the exact configuration that makes it not work.

I can launch a Windows server (AWS Workspace) that has it broken and share credentials - would this help?

It would be this kind of setup:

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?
Our affected clients are on 5.3.5 and 5.4.7 - we will probably move to more recent versions of 5.4 soon, but not to 5.5 yet.

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.
Would appreciate insight into whether 5.3 would also get any updates/patches when you get the chance.

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.
Now trying to see if this is fixable on Magnolia's side.

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
Set the value of dom.w3c_touch_enabled to 0 (which basically disables touch detection in Firefox)

... 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.
I'll keep you posted about any progress on this. Cheers!

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.
I even tested on my MacBook running Sierra and was able to break the page editing functionality (which is normally functional) by enabling "Touch Events API" which is normally set to "Automatic"

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 PAGES-129

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).
Hope this helps.

Comment by Nicole Stutz [ 11/May/17 ]

Hi Federico, Thank you!

Generated at Mon Feb 12 06:15:53 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.