Unable to look at events on calendar

NEW
Unassigned

Status

()

Firefox for Android
General
5 years ago
5 years ago

People

(Reporter: wesj, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Clicking on links in the calendar at doesn't seem to do anything:

http://dayonecenter.com/classes/calendar/san_francisco

On desktop it works fine and shows a detail for the event.

I see a few errors in the console like:

E/GeckoConsole(29798): [JavaScript Error: "TypeError: $(...).getElements is not a function" {file: "https://dayonecenter.com/js/mega/global.js" line: 308}]

E/GeckoConsole(29798): [JavaScript Error: "TypeError: $(...).getElements is not a function" {file: "https://dayonecenter.com/js/mega/global.js" line: 308}]

Neither occur when I'm clicking, but happen during page load. They also both show up on desktop.

Comment 1

5 years ago
(In reply to Wesley Johnston (:wesj) from comment #0)
> Clicking on links in the calendar at doesn't seem to do anything:
> 
> http://dayonecenter.com/classes/calendar/san_francisco

I get a php error when I try to load this url.
(Reporter)

Comment 2

5 years ago
I do too now. Worked an hour ago...
(Reporter)

Comment 3

5 years ago
Site is back up. Looks like this is an iframe with a css transform set on it. Essentially getBoundingClientRect on elements inside that iframe doesn't take the transform into account (which makes sense to me, if you're drawing in that document, you don't want to know about your transform...), but we use getBoundingClientRect to try and wiggle touches onto the correct target. Working on a fix...
(Reporter)

Comment 4

5 years ago
Created attachment 719262 [details] [diff] [review]
WIP Patch 1

This was my first take. Basically to get these transform and take them into account when fixing the event coordinates. It works. It just feels like way to much work. I'm also still not doing things like handling frames where the transform origin is something other than top-left.

I think what I'd rather do is try and look for a better fix to bug 710704 that doesn't use window.top and hence can ignore these transform problems? Or maybe just bail on touch redirection if the element is in an iframe at all...
Assignee: nobody → wjohnston
(Reporter)

Comment 5

5 years ago
Created attachment 719276 [details] [diff] [review]
Patch

This just doesn't do this redirection if we're inside an iframe that has a transform. This is a thousand times simpler and is less likely to break. But its turning off this feature for a (small) subset of pages (i.e. clicks will not work correctly all the time).

I think the simplicity is worth the tradeoff.
Attachment #719276 - Flags: review?(bugmail.mozilla)
Comment on attachment 719262 [details] [diff] [review]
WIP Patch 1

Review of attachment 719262 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah, I don't want to be implementing all of CSS transforms in browser.js
Attachment #719262 - Flags: feedback-
Comment on attachment 719276 [details] [diff] [review]
Patch

Review of attachment 719276 [details] [diff] [review]:
-----------------------------------------------------------------

We use getBoundingClientRect in a lot of places, though. This only addresses one possible code path. And unless I'm misunderstanding the problem, this will only "fix" it for small transforms, right? I mean we use getBoundingClientRect in elementFromPoint, which is used to determine the _highlightElement so even without the "wiggle" code the click will be sent to the wrong element. Minusing for now, but let me know if I'm off base here.
Attachment #719276 - Flags: review?(bugmail.mozilla) → review-
(Reporter)

Comment 8

5 years ago
I agree it would be good to fix this everywhere, but I don't think its trivial. Maybe we can get bug 788073 up and running instead.
(Reporter)

Comment 9

5 years ago
Not actively working on this, but I am working on the other bug. I'll leave this open and recheck once that lands.
Assignee: wjohnston → nobody
You need to log in before you can comment on or make changes to this bug.