Closed Bug 1214446 Opened 9 years ago Closed 8 years ago

event document "selectionchanged" not triggered

Categories

(Core :: DOM: Core & HTML, defect)

41 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1231923

People

(Reporter: bty-adminf1, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36 Steps to reproduce: Try to use into JQ document.addEventListener('selectionchange', function() {...}}) to get and manage selection and create refs to selection; Actual results: The selection of text seems not to raise the event. The selection of text don't pause on stop point in debugger : instruction on event is not executed document.addEventListener('selectionchange', function() {alert('ok');}) tested in spies gives result : undefined I have not found a way in debugger to get the list of events known on "document" and "window" Expected results: This (the full piece of soft) functions in google chrome (win and android) and IE (not others yet tested). The event seems to be defined for Firefox in events list in Mozilla doc. May not already available ? in 41.0.1 I report here because I thought that it was available and not imagine other place to ask this question.
Component: JavaScript: Standard Library → DOM
Bernard, can you please try this on Firefox Nightly? You can download it from <https://nightly.mozilla.org>. Thanks!
This is working nightly. When can we expect this to be in the production build?
(In reply to rtharrison86 from comment #3) > This is working nightly. When can we expect this to be in the production > build? Bug 571294 was fixed in Firefox 43, which was released December, 2015. ( https://wiki.mozilla.org/RapidRelease/Calendar ) Is this not working in the latest released version of Firefox for you?
It's behind a preference which is toggled off outside of nightly - see bug 1231923
I go on following this subject. But because I have implemented a check of the event management in the context, then if it is not available I manage either mouseup-mousedown or touchup touchdown for mobile compatibility (with a check of the OS). I naturally get different behaviors during process but for the case I can get finally the same result (need sometimes a validation button). About the use of the event : The most important difference is the event buffer, because when the event is held an event is triggered by clock when selection changes even the "end" of selection action event, mouse or touch up is not issued. In such case I can treat dynamically the content of the current selection, in the other case I must check at the end... For test an optional configuration display allows to show what is operationally held by any browser in any context. Then the behavior is hidden for current tests (8 browsers, I must add Nightly and plan the check with preference option). I will go back here with results.
(In reply to Andrew McCreight [:mccr8] from comment #4) > (In reply to rtharrison86 from comment #3) > > This is working nightly. When can we expect this to be in the production > > build? > > Bug 571294 was fixed in Firefox 43, which was released December, 2015. ( > https://wiki.mozilla.org/RapidRelease/Calendar ) > > Is this not working in the latest released version of Firefox for you? This is not working on my updated version: the arch package is firefox-44.0.2-2
Ah, sorry, per comment 5 it is not enabled yet outside of Nightly.
(In reply to Andrew McCreight [:mccr8] from comment #8) > Ah, sorry, per comment 5 it is not enabled yet outside of Nightly. Do you have any guess when this might be pushed, of anything I could do to help... I would like to have this feature for a beta test we are doing in April. If it's uncertain, I can work around
(In reply to Andrew McCreight [:mccr8] from comment #8) > Ah, sorry, per comment 5 it is not enabled yet outside of Nightly. Do you have any guess when this might be pushed, of anything I could do to help... I would like to have this feature for a beta test we are doing in April. If it's uncertain, I can work around
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Blocks: 571294
No longer depends on: 571294
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.