Closed Bug 923081 Opened 7 years ago Closed 7 years ago

Long press events are fired in system app when triggered in web content

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla27

People

(Reporter: daleharvey, Assigned: daleharvey)

Details

Attachments

(1 file, 1 obsolete file)

Split from https://bugzilla.mozilla.org/show_bug.cgi?id=915137

  if (IsRemoteTarget(mGestureDownContent))
    return;

in nsEventStateManager::CreateClickHoldTimer prevents this from happening, I am not certain how to test this / how this may effect other behaviour though.

This is not currently causing any visible breakages and kats has mentioned refactorings which may fix this https://bugzilla.mozilla.org/show_bug.cgi?id=920036 so not entirely sure it needs effort, but filing in case
The above doesnt only fixes this if the
Summary: Long press events are fired in system app when triggered in web content → Long press events are fired in system app when triggered in web content (azpc)
Summary: Long press events are fired in system app when triggered in web content (azpc) → Long press events are fired in system app when triggered in web content
This stops the duplicate event being triggered in the parent application for both in browser and proper app content, there doesnt seem to be much that actually gets broken by the duplicate event in the end, but still very confusing.
 
I dont know the best way to test it, so if it requires tests then would appreciate a pointer to something that tests something similiar.

Seeing as I dont think it will actually cause any bugs unless we change the way we handle contextmenu events in the system app, we may want to dupe it to the refactor that fixes it seperately
Assignee: nobody → dale
Attachment #813194 - Flags: feedback?(bugmail.mozilla)
Attachment #813194 - Flags: feedback?(bugmail.mozilla) → feedback?(bugs)
Comment on attachment 813194 [details] [diff] [review]
Dont run contextmenu timer for remote events

Yeah, I think this should be ok.
Just want to make sure e10s doesn't use this for anything
(afaik it doesn't).
Attachment #813194 - Flags: feedback?(bugs) → feedback?(felipc)
Attachment #813194 - Flags: feedback+
Attached patch 923081.patchSplinter Review
Updated since it conflicted, and setting r? as I think its worth checking this in, will push to try
Attachment #813194 - Attachment is obsolete: true
Attachment #813194 - Flags: feedback?(felipc)
Attachment #813499 - Flags: review?
Attachment #813499 - Flags: review? → review?(felipc)
Attachment #813499 - Flags: review?(felipc) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/31aab4ccfcbe
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
(In reply to Dale Harvey (:daleharvey) from comment #6)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/31aab4ccfcbe

Please don't resolve bugs when landing on inbound.
Target Milestone: --- → mozilla27
Sorry, realised my mistake just after I lost internet connection for the night
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.