Syncing all events about browser-sync HOT 60 OPEN

Key events / input change events +1! That's the last thing we need to effectively use BrowserSync with our single page app.

from browser-sync.

This is a feature I desperately want in browser-sync. After the next round of bug fixes, this idea will be getting some serious attention.

from browser-sync.

This will be a GREAT addition.

After some research I couldn't think of a great way to implement this. The less hacky one is to listen to every event on document.documentElement and send then to other devices based on the toElement property of the event.

I see some serious drawbacks with mousemove, touchdrag and other events that are sent a lot.

We could stack then and send to other connected devices with some frequency like 100ms. The frequency should be an option to the user.

Do you guys think of anything more fancy?

from browser-sync.

@hugobessaa I'm working on a much improved way to handle navigation syncing first (I'll push my branch up later so you can have a look) before I dive into this, but I'd be really interested to see what you could come up with.

Right now, any click will force a location:change event, even if you are toggling a menu open on a anchor for example. So my idea is to cache clicks & then when onbodyunload fires, broadcast the last clicked URL.... See any drawbacks? (Apart from ie7 support)?

from browser-sync.

I would recommend we focus on accuracy over latency since almost everyone
would be using it over a LAN.

On Mon, Dec 23, 2013 at 3:32 AM, Hugo [email protected] wrote:

This will be a GREAT addition.

After some research I couldn't think of a great way to implement this. The
less hacky one is to listen to every event on document.documentElementand send then to other devices based on the
toElement property of the event.

I see some serious drawbacks with mousemove, touchdrag and other events
that are sent a lot.

We could stack then and send to other connected devices with some
frequency like 100ms. The frequency should be an option to the user.

Do you guys think of anything more fancy?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-31102974
.

Shane Hudson (Website Developer -
www.ShaneHudson.nethttp://www.shanehudson.net/
)

07794746595

@ShaneHudson https://twitter.com/#!/ShaneHudson / +Shane
Hudsonhttps://plus.google.com/u/0/110111510059204475260

from browser-sync.

@ShaneHudson 👍

from browser-sync.

@shakyShane well, as the link ghostMode already do, you can't have "#" urls with event.preventDefault() because browser-sync force any link to change the location.

The thing we really need is to be able to send any event to other connected devices. e.g.: think of a gallery where the user uses the keyboard arrows to navigate, not links.

from browser-sync.

@ShaneHudson I at least use some network conditioner to really test mobile devices. This could lead to a not great experience. Still need to test it though.

@shakyShane did you see any drawback when implementing scroll ghostMode? It has a 50ms threshold to send another event, don't it? Why?

from browser-sync.

@hugobessaa - I think the 50ms delay was to address a problem with old versions of IE. I should of put it behind an option really because it works fine if users are only developing for modern browsers.

from browser-sync.

This issue now has my full attention (after a huge round of fixes/improvement in other areas).

First, lets focus on clicks. (anchors no longer trigger location changes now, it's done server side).

It's easy enough to capture all clicks with event delegation on the body, but @hugobessaa - I'm struggling to figure out the best way to transmit the event through the socket and replicate it on the other device.

I don't have any experience using toElement - can you explain a little bit about that?

from browser-sync.

Great you will be looking on this! I was getting some things done to work on this next week.

The toElement property of an event is the element you interacted with to send an event. Even if you add an event listener to document.documentElement, you can get what element the user clicked, for example.

You can preview it right on your console window. Run this on your console on this page:

document.documentElement.addEventListener('click', function(e) {
  console.log(e);
});

Now, click on any element (e.g. this paragraph). Now check the toElement of the logged event. I never used this in production, but I think it could work. I know this prop isn't cross-browser.

That's srcElement and target too.

We could emit an 'event' event with the type and element of it. The receiver would trigger that event type on the corresponding element. How we know which element is the corresponding one? I don't know yet.

Please pull the branch you are working to origin. I will be happy to further help you with this.

from browser-sync.

Grabbing the element on which the event was fired is cool - I have that down already.

"How we know which element is the corresponding one? I don't know yet." - that's the part I'm struggling with. When the receiving browser receives info about a click, how the hell does it know which element to fire the click on?

from browser-sync.

^ obviously can't use click co-ordinates, classes or ids

(it's a shame dom elements are not indexed!)

from browser-sync.

We can try to locate it based on the tag. Run some selector like document.getElementsByTagName('span'), get the index of the element that fired the event, and send this info. Run the same selector on the receiver and select the corresponding index.

_That's an ultra-hacky way to do this_, but we are kinda out of known options. Not less hacky than DOM index, though.

from browser-sync.

No that seems like a pretty good idea actually - much better than anything I had in mind.

I'll put some tests together on a branch and ping you when I have something worth looking at.

from browser-sync.

plus, firing the event cross-browser should be a piece of cake as I already use this in tests & it works well.

function fireEvent(obj,evt){

    var evObj;
    var fireOnThis = obj;
    if( document.createEvent ) {
        evObj = document.createEvent("MouseEvents");
        evObj.initEvent( evt, true, false );
        fireOnThis.dispatchEvent( evObj );

    } else if( document.createEventObject ) {
        evObj = document.createEventObject();
        fireOnThis.fireEvent( "on" + evt, evObj );
    }
}

from browser-sync.

I have it working on modern browsers now - check this out

http://quick.as/vxripl1

from browser-sync.

Awesome! This would works also for angular.js bindings, right (just to be sure)?

from browser-sync.

I'm just working on click events at the moment, but yeah - it should work on anything that has a click event attached to it :)

from browser-sync.

That is brilliant! Nicely done :) could you test Google maps? The project
I'm working on is similar to that :) lots of dragging and zooming etc
On 29 Dec 2013 18:12, "Shane Osbourne" [email protected] wrote:

I have it working on modern browsers now - check this out

http://quick.as/vxripl1

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-31321908
.

from browser-sync.

+1

Curious ... Would be hard to support other event types (I am thinking about input text bindings etc) ...? Types can be easily abstracted out in your implementation?

from browser-sync.

@shakyShane WOW! Glad to see the logic working. var elem = event.target || event.srcElement; (source) worked as a solution to your previous comment?

I could also see scrolling working (#31) on your project! Great.

from browser-sync.

@learningjs As the implementation on branch feature/sync-clicks implies, it's tottaly attached to clicks yet. But, the logic could be abstracted to virtually any type of event.

from browser-sync.

@hugobessaa It's in master now & on NPM.

It was pretty easy going using your idea apart from IE < 9 (syncing only works 1 way at the moment)...

RE: scroll - I have to say a huge thanks to you for that! - when you have about 8/9 devices & screens open watching the scroll, it's pretty impressive.

I removed the throttle by default too & now there's virtually no lag at all. :)

from browser-sync.

Great, great code @shakyShane. Tomorrow I will take a look on how we could implement with any event, to fix this issue.

RE: scroll - I was testing on 7 devices of very different sizes the day I came up with that PR. Helped me A LOT, as the rest of the features of this incredible projects. I'm glad we are evolving it even further, and I'm more than happy to share my knowledge for something really useful.

from browser-sync.

Look forward to it - you might as well branch off master now as I'm focussing on a couple of other issues for a while now & master has the latest code re: events.

5 or 6 more bugfixes to sort & then the really big project starts - building the control panel. (That's going to be an angular app)

:)

from browser-sync.

Sorry for the delay here. Work got crazy and I have a very limited time to keep up with this. Next week I'll have more time hopefully and will continue to try to implement this.

from browser-sync.

No worries - excited to improve this feature, but there's no rush. I'm working on the control-panel at the mo which is another pretty big change to the code-base - so be sure to give me shout before you start any work & I'll push it up so you can branch off it (to save a horrible merge later on)

from browser-sync.

Just to be sure, this feature will also handle hover effects (CSS & JS), right?

from browser-sync.

@brush - I'm not sure if you can fake the hover event in a way that would invoke the css selector :hover - I'm guessing that's what you are looking for...

from browser-sync.

@shakyShane I'll try to find out ;-)

from browser-sync.

Both seen easy to implement. ghostMode's form feature do not work to you @robwierzbowski, for form events?

Key events are a great addition. What do you think @shakyShane? I can do this next week or so.

from browser-sync.

Yeah It would be great to get this feature implemented.

the client-side lib is super modular now so it should be easy enough to add https://github.com/shakyShane/browser-sync-client/tree/master/lib

from browser-sync.

Inputs mirror each other, but select boxes don't, and the keyup/input
change events that activate our submit buttons once content has been
entered don't fire.

I can get more specifics if they would be helpful, and am happy to test.

On Wednesday, June 25, 2014, Shane Osbourne [email protected]
wrote:

Yeah It would be great to get this feature implemented.

the client-side lib is super modular now so it should be easy enough to
add https://github.com/shakyShane/browser-sync-client/tree/master/lib

—
Reply to this email directly or view it on GitHub
#22 (comment)
.

Rob Wierzbowski
@robwierzbowski http://twitter.com/#!/robwierzbowski
http://github.com/robwierzbowski
http://robwierzbowski.com

from browser-sync.

Oh, this is true. Will consider this while implementing these new syncing features. Just wait for the next week, when I'll have time to implement this 🚀

from browser-sync.

👏 👏 💃

from browser-sync.

@robwierzbowski select boxes should work...

from browser-sync.

Huh. Without derailing this thread, any ideas what my issue could be? Using <select> with a name, in a form with an id.

from browser-sync.

Hi! First of all browser-sync is awesome so far. Thank you guys so much for it!

I'm working on a SPA and submitting a form (whereas the actual submit/relocation is prevented) is not synched at the moment, is that correct?

from browser-sync.

Has there been any more progress on this?

from browser-sync.

Just tried to put a simple version of keyboard events working. It looks like triggering keyboard events properly is pretty difficult.

Here is a WIP of this feature on my fork of browser-sync-client: https://github.com/hugobessaa/browser-sync-client/commit/7d5a8a085c51d5d901c0a05b46ece20fa6060a98

It's already triggering keyup and keydown events on inputs and textareas, but I couldn't make it send the right event.keyCode.

I think most folks use keyboard events to capture the pressed key. This is a must for this feature. I will keep looking for a way to do that.

from browser-sync.

+1 for syncing click events across browsers

from browser-sync.

+1
Any more progress on here?

from browser-sync.

I'm using v2.5.3 and just noticed this seems to be (at least partly) done... clicks are being sync'd between browsers for me 👍

But details about the real click are not being carried over to the other browser, eg event.which, event.button, event.ctrlKey, event.shiftKey, event.metaKey etc

from browser-sync.

is this still being worked on?

from browser-sync.

+1 I'm running into the click syncing issue for links that use e.preventDefault(). Should that work now?

from browser-sync.

+1

from browser-sync.

+1

from browser-sync.

+1

from browser-sync.

+1

from browser-sync.

Hi guys!

I'm trying to implement something like simple 'my custom event sync'. So my idea was to capture the event and send the message to server which will then emit it to other clients. Can You maybe point me to the right direction? I was tinkering with ___ browserSync ___.socket.emit('evt'); on client and bs.sockets.on('evt'); from browsersync's API but with no luck. I can see that I can emit events from srv to client with bs.sockets.emit but how to emit from client to srv?

BTW. great project.

Thanks in advance!

from browser-sync.

Amazing extension man... I am trying to wrap my mind around it. I see your example of onclick events working. I am using jquery with namespaced click events and it doesn't appear to work. I tried removing the namespace and it still wouldn't trigger. Is it because im not doing vanilla js events and running it through jquery?

from browser-sync.

+1

from browser-sync.

+1

from browser-sync.

+1, any work on onchange event?

from browser-sync.

+1 onchange :)

from browser-sync.

I'm voting for at least implementing input value change events.

from browser-sync.

+1 for eventListener change triggers.

from browser-sync.

Did anything ever get done to make it so we can specify how change, update, keydown/up events are synced?

When dealing with SPAs updating the fields contents is not enough if that framework is listening for specific types of events.

from browser-sync.

Working on Polymer. Is it in pipeline to sync events for elements inside ShadowRoot ?

from browser-sync.