1138335 - Joomla! CMS admin menu doesn't work with Firefox for Android

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[joomla]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150222232811

Steps to reproduce:

- Go to http://demo.joomla.org with Firefox for Android
- Find 'Launch Test Drive' button on the bottom and tap on it. It will create a fresh Joomla site for you.
- Try to tap on the menu icon on the top right corner of the window


Actual results:

The browser opens a new tab with the frontpage of the site, because there is a 'preview' button behind the menu button.


Expected results:

It should open the admin menu with the components and other parts of the system. 
It works well with the stock browser.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

This is almost certainly webkit specific css issues.

Comment 2

[Hallvord R. M. Steen [:hallvors]]

I don't notice any -webkit CSS that doesn't have equivalents - the site is doing a pretty good job at using various prefixes.

The menu icon is an A element styled as block and floated right. With this styling it is meant to end up overlapping the Joomla! link which is a normal inline and styled float:none. This A element does not however have a HREF, so the expected functionality depends on the expected JavaScript onclick firing and preventing the default action. Does the site perhaps fail to attach the event handler when it fails?

Comment 3

[Hallvord R. M. Steen [:hallvors]]

It seems to already work much better if I simply add href="#" to this element:

<a class="btn btn-navbar collapsed" data-toggle="collapse" data-target=".nav-collapse" id="foo">

So it looks like a very subtle issue with how the browser determines target for touch events, but I can't quite set my finger on what's wrong..

[Pun intended)

Comment 4

[Kevin Brosnan [Ex-Mozilla]]

Thanks for investigating. Given what was found I suspect that this may show an issue with the what did you tap on code.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

When I try the STR in nightly I get an SSL error saying there's no overlap in available ciphers. In Release though when I tap on the button the background bar highlights and a new window opens up. That may or may not be a Fennec bug, but I'd have to repro with logging to say. Which I probably won't be able to do until the SSL thing is fixed.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Also on release I'm constantly hitting bug 1130978 and crashing.

Comment 7

[Hallvord R. M. Steen [:hallvors]]

Attachment: Demo - 1138335.htm

This is a demo which is a bit minimised but not a lot (plenty of CSS is superfluous). What happens here is that Firefox opens a bogus tab on the touch, while Chrome does nothing. I'm not sure if it's exactly equivalent given that the JS that opens the menu in Chrome is removed, but it does show a potentially interesting activation behaviour difference..

Comment 8

[Klipper]

I can confirm this bug.
I've same problem with Joomla administrator menu (J3.4.1) on latest Firefox for Android (38.0.5) both on a Samsung Galaxy S5plus phone en a Nexus 7 (2012). When pushing the administrator menu hamburger button a new tab opens with the frontend of the site instead opening the menu. This happens on multiple different sites.

Comment 9

[Hallvord R. M. Steen [:hallvors]]

To reproduce, open demo in Firefox on Android and tap the top right menu button. If a new tab opens, it's a fail.

Comment 10

[Hallvord R. M. Steen [:hallvors]]

kbrosnan: the demo should make it a bit easier to analyse this - less code.. Can you push this towards somebody who knows touch handling code?

Comment 11

[Kartikaya Gupta (email:[e-mail])]

I looked at the reduced test case in WebIDE while reproducing the issue in Nightly - there's nothing particularly odd going on there. Tapping anywhere in the header hits the anchor tag with target="_blank" and href="https://j1233g101.demojoomla.com", which as expected opens that URL in a new window. The same appears to happen in Chrome. I suspect the attached demo is an over-reduction of the original case.

I'm still seeing the SSL error I mentioned in comment 5 on the live website demo.joomla.org.

Comment 12

[Hallvord R. M. Steen [:hallvors]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #11)
> The same appears to happen in Chrome.

In Chrome on Android tapping *on* the top right "burger-style" menu button does nothing. Tapping elsewhere does indeed open the non-existing page. You don't see the menu button tap behaving differently?

Comment 13

[Kartikaya Gupta (email:[e-mail])]

Ah, that's true, it does behave differently if I tap right on the menu button. The button is really an <a> tag with no href and no event listener, so in Gecko we treat it as non-clickable. The code to find the nearest clickable target ends up targeting the clickable anchor instead, and so we use that. Presumably Chrome doesn't do this.

On the full page I would expect that some sort of listener would be registered on the menu button and so it would get treated as clickable. But perhaps that isn't happening?

Comment 14

[Hallvord R. M. Steen [:hallvors]]

Attachment: Demo - 1138335.htm

The click event listener is on document. It gets confused because Gecko has done some extra magic to find the element it considers "activatable" and thus event.target is not the elements that make up the menu button - it's the nearby A element. Hence, the code for expanding/collapsing the menu is never run. See new demo.

Comment 15

[Kartikaya Gupta (email:[e-mail])]

Hm, that's a tricky problem to solve then. We explicitly ignore listeners on the body or document (as of bug 901117) when assessing clickability for fluffing since that would prevent fluffing of targets on the entire page and make it harder to click things. We need to come up with some way to distinguish this case from that one programmatically.

Wes, any thoughts on this?

Comment 16

[Hallvord R. M. Steen [:hallvors]]

We had pretty much exactly the same problem when Opera's "spatial navigation" logic needed to find elements to navigate to. GMail at some point had a global click handler processing all the actions for the various clickable elements in the UI - made it pretty much impossible to figure out navigation heuristics.

You could make a small hack and consider <A> elements clickable even without HREF - would probably fix this case - but I think this problem can't be entirely resolved.

Comment 17

[Hallvord R. M. Steen [:hallvors]]

If Chrome on mobile gets away with doing less of what you call "fluffing" maybe we should simply remove some code? How much "fluffing" is required for a good UX? Is it really ever a good idea to have the user clicking "through" an element and hit the link behind it - absent any pointer-events:none magic? In other words - was this part of the "fluffing" algorithm implemented based on sites that worked better with this behaviour, or is it more theoretical?

Comment 18

[Hallvord R. M. Steen [:hallvors]]

(It's easy enough to ask Joomla devs to just add href="#" to their menu code, BTW - but Joomla is big and has many deployments so upgrading would take ages, plus we may hit similar problems elsewhere.)

Comment 19

[Kartikaya Gupta (email:[e-mail])]

We ran into a different but related problem over in bug 1181763 and I think the fix for that bug should fix this one as well. Stay tuned.

Comment 20

[Wesley Johnston (:wesj)]

Maybe we give up fluffing if there's a click handler on the body... Oh, reading on there's a fix. yay! clearing need-info

Comment 21

[Kartikaya Gupta (email:[e-mail])]

There's going to be a dependency relationship here, I think. The patch I posted to bug 1181763 doesn't fix this directly but with some additional work it should allow doing so.

Comment 22

[Kartikaya Gupta (email:[e-mail])]

Attachment: WIP

The additional work will look something like this. Stashing it here for now. I tried this on top of the patch in bug 1181763, and while it does sort of fix the problem it also causes the cluster detection to fire a lot more so it will need some tweaking.

Comment 23

[Hallvord R. M. Steen [:hallvors]]

Found another site that seems broken by this - reported in https://webcompat.com/issues/1464

Comment 24

[Hallvord R. M. Steen [:hallvors]]

Attachment: nor-way.demo.htm - showing the problem in the webcompat.com issue

Comment 25

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.