JavaScriptEnabled

[Jacques Le Roux <ja...@les7arts.com>]

Hi,

Should we still keep JavaScriptEnabled in soon 2025, and if so why?

TIA

Jacques

Re: JavaScriptEnabled

[Jacques Le Roux <ja...@les7arts.com>]

Le 28/10/2024 à 16:04, Daniel Watford a écrit :
> I now realise that it is used to detect whether the browser has JavaScript
> enabled, often conveyed from the browser to the server through a hidden
> form field.

Hi Daniel,

Yes that's mostly it indeed. JavaScriptEnabled=Y can also be passed as a query string parameter.

Thanks

Jacques

Re: JavaScriptEnabled

[Jacques Le Roux <ja...@les7arts.com>]

Le 28/10/2024 à 17:17, Michael Brohl a écrit :
>
> I generally agree with everything you have described here with one addition: standard functionality should detect that JavaScript is disabled in the 
> browser and render an appropriate message to the user, that activating JavaScript is mandatory. 

Hi Michael,

That's an interesting and important point indeed.

Thanks

Jacques

Re: JavaScriptEnabled

[Michael Brohl <mi...@ecomify.de>]

Hi Dan,

thanks for your thorough evaluation.

I generally agree with everything you have described here with one 
addition: standard functionality should detect that JavaScript is 
disabled in the browser and render an appropriate message to the user, 
that activating JavaScript is mandatory.

A very brief check shows that the flag is also uses for setting 
UserPreferance; this is not clear to me. I would like to check in the 
next days and also consult with the team to check if there are any more 
aspects we have to take into account.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 28.10.24 um 16:04 schrieb Daniel Watford:
> Hi Jacques,
>
> Before I could answer your message, I had to spend some time reviewing
> every location that I could find JavaScriptEnabled in the code to ensure I
> understood its purpose.
>
> I now realise that it is used to detect whether the browser has JavaScript
> enabled, often conveyed from the browser to the server through a hidden
> form field.
>
> OFBiz code has lots of branch conditions around the JavaScriptEnabled flag
> so I believe that - assuming we are happy to have JavaScript as a
> requirements to run OFBiz - we should remove (or atleast deprecate) the
> flag with an assumption that JavaScript is always present. This might mean
> that users without JavaScript enabled have a degraded experience for the
> future 25.x OFBiz release. However, I doubt many of us in the developer
> community habitually test OFBiz with javascript disabled to ensure that
> experience remains the same.
>
> I see the benefits of removing this flag as the opportunity to simplify
> numerous examples of branching logic and removal of code.
>
> I would like to see the v24.x release notes include a statement that future
> major releases of OFBiz will require javascript to be enabled in the
> browser for correct behaviour.
>
> For the cases you highlighted - <"JavaScriptEnabled" value="N"> - does
> anyone know the intention behind disabling javascript for the subsequent
> form submission? For the Login.ftl cases, although the hidden
> JavaScriptEnabled form input is set to 'N', javascript running on the page
> later sets the value to 'Y'.
>
> Thanks,
>
> Dan.
>
> On Mon, 28 Oct 2024 at 09:33, Jacques Le Roux <ja...@les7arts.com>
> wrote:
>
>> Le 27/10/2024 à 13:35, Jacques Le Roux a écrit :
>>> Le 26/10/2024 à 13:01, Jacques Le Roux a écrit :
>>>> Hi,
>>>>
>>>> Should we still keep JavaScriptEnabled in soon 2025, and if so why?
>>>>
>>>> TIA
>>>>
>>>> Jacques
>>> Please forget this inappropriate question
>>>
>>> Jacques
>> Hi,
>>
>> My question was not well expressed, if not cryptic.
>> Here is hopefully a better formulated question with a bit of explanation.
>>
>> We are in 2025 and obviously JavaScript is everywhere.
>>
>> JavaScriptEnabled is an old concept of the pre Apache era, it has more
>> than 20 years!
>> Without it a lot of features, like form fields autocompleting, are
>> unavailable.
>>
>> I propose to not change any code but to set JavaScriptEnabled to true when
>> the user is signing in.
>> Note that this is already automatically done when you put
>> JavaScriptEnabled=Y in the login URL
>> as in /control/login?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
>> Unfortunately, that's not an obvious feature and may depreciate OFBiz
>> value when evaluated without it.
>>
>> There are few cases, in plugins and themes, where JavaScript is not
>> wanted, hence JavaScriptEnabled sets to false,
>> (look for <<"JavaScriptEnabled" value="N">>).
>> That's not a problem, because it's only in forms and does not change the
>> initial session value of JavaScriptEnabled.
>>
>> So my question is do we need a vote to apply this change?
>>
>> TIA for your participation
>>
>> Jacques
>>
>>

Re: JavaScriptEnabled

[Daniel Watford <da...@foomoo.co.uk>]

Hi Jacques,

Before I could answer your message, I had to spend some time reviewing
every location that I could find JavaScriptEnabled in the code to ensure I
understood its purpose.

I now realise that it is used to detect whether the browser has JavaScript
enabled, often conveyed from the browser to the server through a hidden
form field.

OFBiz code has lots of branch conditions around the JavaScriptEnabled flag
so I believe that - assuming we are happy to have JavaScript as a
requirements to run OFBiz - we should remove (or atleast deprecate) the
flag with an assumption that JavaScript is always present. This might mean
that users without JavaScript enabled have a degraded experience for the
future 25.x OFBiz release. However, I doubt many of us in the developer
community habitually test OFBiz with javascript disabled to ensure that
experience remains the same.

I see the benefits of removing this flag as the opportunity to simplify
numerous examples of branching logic and removal of code.

I would like to see the v24.x release notes include a statement that future
major releases of OFBiz will require javascript to be enabled in the
browser for correct behaviour.

For the cases you highlighted - <"JavaScriptEnabled" value="N"> - does
anyone know the intention behind disabling javascript for the subsequent
form submission? For the Login.ftl cases, although the hidden
JavaScriptEnabled form input is set to 'N', javascript running on the page
later sets the value to 'Y'.

Thanks,

Dan.

On Mon, 28 Oct 2024 at 09:33, Jacques Le Roux <ja...@les7arts.com>
wrote:

> Le 27/10/2024 à 13:35, Jacques Le Roux a écrit :
> > Le 26/10/2024 à 13:01, Jacques Le Roux a écrit :
> >> Hi,
> >>
> >> Should we still keep JavaScriptEnabled in soon 2025, and if so why?
> >>
> >> TIA
> >>
> >> Jacques
> >
> > Please forget this inappropriate question
> >
> > Jacques
>
> Hi,
>
> My question was not well expressed, if not cryptic.
> Here is hopefully a better formulated question with a bit of explanation.
>
> We are in 2025 and obviously JavaScript is everywhere.
>
> JavaScriptEnabled is an old concept of the pre Apache era, it has more
> than 20 years!
> Without it a lot of features, like form fields autocompleting, are
> unavailable.
>
> I propose to not change any code but to set JavaScriptEnabled to true when
> the user is signing in.
> Note that this is already automatically done when you put
> JavaScriptEnabled=Y in the login URL
> as in /control/login?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
> Unfortunately, that's not an obvious feature and may depreciate OFBiz
> value when evaluated without it.
>
> There are few cases, in plugins and themes, where JavaScript is not
> wanted, hence JavaScriptEnabled sets to false,
> (look for <<"JavaScriptEnabled" value="N">>).
> That's not a problem, because it's only in forms and does not change the
> initial session value of JavaScriptEnabled.
>
> So my question is do we need a vote to apply this change?
>
> TIA for your participation
>
> Jacques
>
>

-- 
Daniel Watford

Re: JavaScriptEnabled

[Jacques Le Roux <ja...@les7arts.com>]

Le 27/10/2024 à 13:35, Jacques Le Roux a écrit :
> Le 26/10/2024 à 13:01, Jacques Le Roux a écrit :
>> Hi,
>>
>> Should we still keep JavaScriptEnabled in soon 2025, and if so why?
>>
>> TIA
>>
>> Jacques
>
> Please forget this inappropriate question
>
> Jacques

Hi,

My question was not well expressed, if not cryptic.
Here is hopefully a better formulated question with a bit of explanation.

We are in 2025 and obviously JavaScript is everywhere.

JavaScriptEnabled is an old concept of the pre Apache era, it has more than 20 years!
Without it a lot of features, like form fields autocompleting, are unavailable.

I propose to not change any code but to set JavaScriptEnabled to true when the user is signing in.
Note that this is already automatically done when you put JavaScriptEnabled=Y in the login URL
as in /control/login?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
Unfortunately, that's not an obvious feature and may depreciate OFBiz value when evaluated without it.

There are few cases, in plugins and themes, where JavaScript is not wanted, hence JavaScriptEnabled sets to false,
(look for <<"JavaScriptEnabled" value="N">>).
That's not a problem, because it's only in forms and does not change the initial session value of JavaScriptEnabled.

So my question is do we need a vote to apply this change?

TIA for your participation

Jacques

Re: JavaScriptEnabled

[Jacques Le Roux <ja...@les7arts.com>]

Le 26/10/2024 à 13:01, Jacques Le Roux a écrit :
> Hi,
>
> Should we still keep JavaScriptEnabled in soon 2025, and if so why?
>
> TIA
>
> Jacques

Please forget this inappropriate question

Jacques