Our current touch event code allows sending the radius of the touch. We (try) to send the size in pixels on the scren from Java to Gecko. We should (somewhere) scale that so that the page gets something in its current coordinate system.
Is this really desirable? One of the main reasons I zoom in is so I have finer control over where I can touch (specially with respect to clicking links). This would be negated if we scale the touch radius to match the zoom level.
It should do the opposite I think. Currently, if you zoom in 10x, we'll still tell the page r=1px. If they draw something one pixel in size, our displayport zoom will scale it to be 10pixels in size. We should tell them that its .1px I think?
Ah, I see what you mean. I think we might both be saying the same thing: the radius should be constant in device pixels, and the CSS pixel value should be scaled accordingly. So if we're zoomed at 10x and the r=1px in device pixels, that corresponds to 0.1px in CSS pixels.
blocking-fennec1.0: --- → ?
Does this break any sites? Also, what do other browsers do?
tracking-fennec: --- → 15+
We're the only browser that supports radius right now (that I know of, although I haven't had time to test everyone recently). No sites use this (need to write some neat demos).
Hi, I'm new to firefox development. Going to start looking into this bug.
Great! Step 1 is to get things building. There are pretty detailed instructions on that here: https://wiki.mozilla.org/Mobile/Fennec/Android Feel free to ask questions here, through email, or on irc in the #mobile channel.
I too would like to work on this bug. Is it possible to have more than one person working on it at once, or does that cause problems? Thanks, Michael Nares
Brian, are you still working on this? (In reply to Michael Nares from comment #8) > I too would like to work on this bug. Is it possible to have more than one > person working on it at once, or does that cause problems? Generally only one person works on a bug at a time. If an issue is big enough for two people to work on it, we split it into multiple bugs :) That being said, it looks like Brian hasn't touched this in a while. Let's see if he's made any progress on this, and if isn't working on it, you're free to take it on! In the meantime, you should follow wesj's suggestion in comment 7 and make sure to get a build environment set up before starting work on a specific bug.
I have now find another bug to work on.
Also for future reference it looks like Brian is not looking into this.
I apologize for the delay in getting back to all of you. I have been busy starting a new job and have not had time to look into this like I had planned. I am currently not working on this bug, but if it's still open sometime in the future I may be available to do so. Thank you, Brian
Hi Wesley, I would like to help with this bug. Would you please provide more info on this, like which file and functions I should look at? Thanks, Ming
I started digging to get you some pointers, and think kats may have actually already fixed this. http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoEvent.java#431 Lets have him verify...
Flags: needinfo?(wjohnston) → needinfo?(bugmail.mozilla)
Oh, I guess I did. I landed that change as part of bug 803207 pretty recently. Sorry I stole a mentored bug!
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Depends on: 803207
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.