Generator-jhipster: BrowserSyncPlugin ghostMode

[yelhouti]

Overview of the issue

This is the second time I wasted few hours trying to debug authentication (sso) performed on a non visible tab, to find out that browserSync is messing with me performing the same clicks on the other tab.
I would suggested disabling ghostMode (enabled by default). What do you guys think? is anyone using this?

Motivation for or Use Case

People who wants it can activate it, the other don't need to dig for hours to understand what's happening in there browser.

Reproduce the error

Open two tabs, open menu in one tab, it's open in the other.

Suggest a Fix

I can make a PR, but basically edit the webpack dev config and add:

            ghostMode: {
                clicks: false,
                location: false,
                forms: false,
                scroll: false
            }
        }

JHipster Version(s)

6.6.0

• [X] Checking this box is mandatory (this is just to show you read everything)

[mraible]

I don't understand why this is a problem. The whole point of Browsersync is to sync across browsers and tabs.

[yelhouti]

@mraible I thought it was added in the beginning for livereload, but here is why it's a problem for me:
When I have 2 tabs open:
I click menu + login in a tab, go through authentification, the 2 tabs are are logged in, in dev mode (since both did the same operations, I didn't know that), and when I do that in prod, they are not, debugging that before even knowing that I have browserSync and that browserSync does that messed with my head...

[vishal423]

I agree with @mraible as the intended purpose is to test the application layout across different screen sizes/resolutions without requiring the user to perform a repetitive operation on each screen.

[yelhouti]

I'm not saying it's not great, I'm just saying that it should be disabled by default not to confuse people...

[mraible]

If we make the change you're suggesting, will it still sync between multiple browsers (e.g., Firefox and Chrome)? If not, I think we should keep the current settings.

[yelhouti]

I fill like I didn't explain well what my problem is. IMO, jhipster should NOT have any feature that changes the behavior of the browser without the developer enabling it, this creates too much (unneeded) confusion, and wastes a lot of time debugging problems that shouldn't exist.

I get that the plugin is useful, but if everyone using it, without knowing, couldn't wastes hours debugging problems created by a plugin he didn't install (knowingly) then I think it should be disabled by default.

[murdos]

I think it should be enabled by default, because having sync between multiple browsers is a more frequent use case than debugging authentication for an usual jhipster user.

[yelhouti]

@murdos that is not the only thing people might be debugging...I have used JHipster for more than a year before knowing that this feature exists so...

[pascalgrimaud]

I would suggest to keep the current behavior. Then we can document this part and explain how to disable it.
So everybody will be happy.

Are you ok @yelhouti ? Can you PR the documentation plz ?

[gmarziou]

This could be confusing for new users, I have answered at least 2 questions about it on stackoverflow like this one.

[yelhouti]

@gmarziou thank you, that is exactly my point. @pascalgrimaud I'm sorry I can not agree, I am not trying to force my opinion on others. I just feel that documenting this wouldn't help at all.
Once you understand why your browser is acting weird, it is easy to disable. Before that, you feel like banging your head against a wall. This is the kind of features, IMO, unless asked for (enabled manually) shouldn't be enabled. I will let you guys decide.

[vishal423]

I believe synchronization across multiple devices is the primary reason to have it included as default in JHipster. Do you see other benefits that it provides on top of webpack-dev-server? If we go with the proposed change, then, why should we keep this integration in the first place?

[gmarziou]

In fact, having browser-sync enabled by default violates the principle of least surprise.

I note that none of the frontend framework CLIs offers it by default.

Personally, I'm not a big fan of this feature, I see it mainly used during conference talks to get a wow effect. At work, I would rather use it in QA testing but it's not possible because it isn't available in production builds (for obvious reasons).

A less surprising option would be that browser-sync offers to only enable ghost mode between different browsers and exclude tabs from same browser. This would compare rendering between firefox and chrome for example. Maybe this is a feature request we could submit to browsersync project?

[vishal423]

I always thought about it as a value-add provided by JHipster. I don't use it enough in my projects to have a strong bias to include as default. If everyone agrees, we can remove it from JHipster in v7 along with migration to Angular CLI.

[yelhouti]

I think we can keep the config commented for example, as same people might be unhappy removing it completely, it could also be added in the documentation tips& tricks part... @gmarziou thank for pointing out the principal violated I didn't know about the name of it. but it sure felt wrong for me...

[wmarques]

I don't like commented code in what generate, we either remove it and provide a tip in the doc, or we keep it.

I would vote for removing this, I agree that this is quite nice to show this during conference but not really valuable every day.

[gmarziou]

What about documenting it in generated project's README.md?

[gmarziou]

I submitted an idea to Browsersync project as they are requesting suggestions for their future 3.0 version: https://github.com/BrowserSync/browser-sync/issues/1739

[yelhouti]

@gmarziou nice thing you proposed, but feel that adding to the README wouldn't have helped me (or the other people) understand the problem. I feel that if you didn't enable the sync you wouldn't think it would create problems for you.

[gmarziou]

@yelhouti yes you're right.

[pascalgrimaud]

so how can we advance on this, as some of you want to keep it, some other want to remove...

hard to make all people happy: I think the best would be to document it, add some comments in code, add some information in readme, to explain how to disable

who would like to do it ?

[SudharakaP]

@pascalgrimaud : Done. Let me know if you see any issues :smile: