When checking a recent package, I was surprised to find that I had ordered 16
dark red slopes and 18 dark blue gems.
I think this goes back to something I noticed on or about July 14th where the
store Wanted List page was misbehaving. On that page, with the items from my
personal Wanted List shown, I moved down the page clicking on the up arrow 1,
2, 4, or whatever times. At the bottom, I clicked Add Items to Cart, and got
a "You can't buy more than is available" error because it was trying
to add 40+ of a part. I hadn't clicked 40 times.
This seemed to be reproducible at the time. I reviewed all of my carts and cleaned
up the obvious over-orders. Guess I missed a few.
What it's doing today is:
* Click on up arrow once
* Immediately move cursor down
Sometimes the field changes to '1' and then to '0'.
This is with the latest Safari on the latest macOS. Anyone else able to repro?
What it's doing today is:
* Click on up arrow once
* Immediately move cursor down
Sometimes the field changes to '1' and then to '0'.
This is with the latest Safari on the latest macOS. Anyone else able to repro?
Yes that is standard bricklink behaviour. When a qty field is selected and you
scroll it changes the qty up or down. It’s a weird “feature” that we wish they
would remove (it even applies to refund fields…)
Yes that is standard bricklink behaviour. When a qty field is selected and you
scroll it changes the qty up or down. It’s a weird “feature” that we wish they
would remove (it even applies to refund fields…)
Yes that is standard bricklink behaviour. When a qty field is selected and you
scroll it changes the qty up or down. It’s a weird “feature” that we wish they
would remove (it even applies to refund fields…)
Yes that is standard bricklink behaviour. When a qty field is selected and you
scroll it changes the qty up or down. It’s a weird “feature” that we wish they
would remove (it even applies to refund fields…)
This is how web pages work
It doesn’t happen on all number inputs tho
Because code can catch the wheel event and make it do nothing for those fields.
I guess some pages have it?
Do you know a BrickLink page with this behaviour in particular?
Yes that is standard bricklink behaviour. When a qty field is selected and you
scroll it changes the qty up or down. It’s a weird “feature” that we wish they
would remove (it even applies to refund fields…)
This is how web pages work
It doesn’t happen on all number inputs tho
Because code can catch the wheel event and make it do nothing for those fields.
indeed, hence why the fact they left it on some pages can be considered a "feature"
when they could have disabled it. just like how they have it setup so for some
modals you can click outside the modal to close it and others you can only click
on the X to close it.
I guess some pages have it?
Do you know a BrickLink page with this behaviour in particular?
the number input on the fields you use to send invoices. For a moment I thought
that it didn't have that behaviour because it didn't have the up and
down arrows like the shopping one however the refund one doesn't have arrows
either but still has that weird "feature"
[…]
indeed, hence why the fact they left it on some pages can be considered a "feature"
when they could have disabled it. just like how they have it setup so for some
modals you can click outside the modal to close it and others you can only click
on the X to close it.
Modals are not “native” (not Javascript, not HTML), they are made with CSS.
That means you need to “program” them with CSS or use some CSS code that does
it for you.
So you can easily do it differently from one page to another, depending when
/ how the page was written.
Also, you then have this great feature of CSS: they are Cascading (that’s what
the C stands for). That means there’s a hierarchy of definitions and if you
change something on top of the tree, that may change something at the bottom
(er, yes the tree is roots up…), where you coded your modal. That means you
add a css file for some new part of your page, and that screws up another part
of the page….
OTOH, number entries are native HTML elements («input» tag inside a «form»).
One doesn’t need to recode them entirely. You just give them options.
Now, AFAICT, to prevent the scroll thing to work on number inputs, you need to
disable the wheel event on the input element when it’s got focus. That can only
be done in Javascript (which is what handles events). And you need to be careful
not to disable scrolling altogether.
And then some people will find it annoying to have to click/move outside the
field before being able to scroll….
I guess some pages have it?
Do you know a BrickLink page with this behaviour in particular?
the number input on the fields you use to send invoices. For a moment I thought
that it didn't have that behaviour because it didn't have the up and
down arrows like the shopping one however the refund one doesn't have arrows
either but still has that weird "feature"
I can’t test that page. But I tested on a WL: using the wheel (actually two-fingers
slide on my touchpad) on a focused Qty field both changes the value and scrolls
the page… but the change of value stops as soon as the field is not under the
pointer anymore, and that can happen very fast, even before the value is changed
at all.
So the question is: Are you sure the numbers never change with a scroll on that
page or is it just luck?
[…]
indeed, hence why the fact they left it on some pages can be considered a "feature"
when they could have disabled it. just like how they have it setup so for some
modals you can click outside the modal to close it and others you can only click
on the X to close it.
Modals are not “native” (not Javascript, not HTML), they are made with CSS.
That means you need to “program” them with CSS or use some CSS code that does
it for you.
So you can easily do it differently from one page to another, depending when
/ how the page was written.
The point i was getting at is the inconsistency part not the default part. as
with the inputs they use a variety of different inputs some of which have the
scroll option and some dont. they could change how its setup so they all work
the same as the ones that dont have the "default feature" which is what
would be great
Also, you then have this great feature of CSS: they are Cascading (that’s what
the C stands for). That means there’s a hierarchy of definitions and if you
change something on top of the tree, that may change something at the bottom
(er, yes the tree is roots up…), where you coded your modal. That means you
add a css file for some new part of your page, and that screws up another part
of the page….
OTOH, number entries are native HTML elements («input» tag inside a «form»).
One doesn’t need to recode them entirely. You just give them options.
Now, AFAICT, to prevent the scroll thing to work on number inputs, you need to
disable the wheel event on the input element when it’s got focus. That can only
be done in Javascript (which is what handles events). And you need to be careful
not to disable scrolling altogether.
And then some people will find it annoying to have to click/move outside the
field before being able to scroll….
or just have it that scrolling works fine and you dont have to click/move out
to scroll. right now scrolling both scrolls the page and changes the input. they
could add some script so it just "blocks" it from changing the input
and it would still scroll
I guess some pages have it?
Do you know a BrickLink page with this behaviour in particular?
the number input on the fields you use to send invoices. For a moment I thought
that it didn't have that behaviour because it didn't have the up and
down arrows like the shopping one however the refund one doesn't have arrows
either but still has that weird "feature"
I can’t test that page. But I tested on a WL: using the wheel (actually two-fingers
slide on my touchpad) on a focused Qty field both changes the value and scrolls
the page… but the change of value stops as soon as the field is not under the
pointer anymore, and that can happen very fast, even before the value is changed
at all.
So the question is: Are you sure the numbers never change with a scroll on that
page or is it just luck?
I was going to do more testing but the buyer now paid for their order so I cant
test it again rn
I can’t test that page. But I tested on a WL: using the wheel (actually two-fingers
slide on my touchpad) on a focused Qty field both changes the value and scrolls
the page… but the change of value stops as soon as the field is not under the
pointer anymore, and that can happen very fast, even before the value is changed
at all.
So the question is: Are you sure the numbers never change with a scroll on that
page or is it just luck?
I was going to do more testing but the buyer now paid for their order so I cant
test it again rn
I just tested it on my quote page and can confirm even with the mouse focused
on the number input and scrolling it doesn't change it even when I tho I
could manually enter the number
[…]
The point i was getting at is the inconsistency part not the default part.
Spaghetti code leads to inconsistency.
[…]
Now, AFAICT, to prevent the scroll thing to work on number inputs, you need to
disable the wheel event on the input element when it’s got focus. That can only
be done in Javascript (which is what handles events). And you need to be careful
not to disable scrolling altogether.
And then some people will find it annoying to have to click/move outside the
field before being able to scroll….
or just have it that scrolling works fine and you dont have to click/move out
to scroll. right now scrolling both scrolls the page and changes the input. they
could add some script so it just "blocks" it from changing the input
and it would still scroll
What I was trying to explain is that, as I understand it, it can’t be done.
You can’t say “don’t change the value on wheel events but continue scrolling.”
You can only say “ignore the wheel events when that input has focus.”
And if you ignore the wheel events, you ignore both the value change and the
scrolling.
[…]
The point i was getting at is the inconsistency part not the default part.
Spaghetti code leads to inconsistency.
indeed
[…]
Now, AFAICT, to prevent the scroll thing to work on number inputs, you need to
disable the wheel event on the input element when it’s got focus. That can only
be done in Javascript (which is what handles events). And you need to be careful
not to disable scrolling altogether.
And then some people will find it annoying to have to click/move outside the
field before being able to scroll….
or just have it that scrolling works fine and you dont have to click/move out
to scroll. right now scrolling both scrolls the page and changes the input. they
could add some script so it just "blocks" it from changing the input
and it would still scroll
What I was trying to explain is that, as I understand it, it can’t be done.
You can’t say “don’t change the value on wheel events but continue scrolling.”
You can only say “ignore the wheel events when that input has focus.”
And if you ignore the wheel events, you ignore both the value change and the
scrolling.
that would be a bit surprising. I've deal with (probably to much) script
and it can do just about anything if you set it up right
[…]
The point i was getting at is the inconsistency part not the default part.
Spaghetti code leads to inconsistency.
indeed
[…]
Now, AFAICT, to prevent the scroll thing to work on number inputs, you need to
disable the wheel event on the input element when it’s got focus. That can only
be done in Javascript (which is what handles events). And you need to be careful
not to disable scrolling altogether.
And then some people will find it annoying to have to click/move outside the
field before being able to scroll….
or just have it that scrolling works fine and you dont have to click/move out
to scroll. right now scrolling both scrolls the page and changes the input. they
could add some script so it just "blocks" it from changing the input
and it would still scroll
What I was trying to explain is that, as I understand it, it can’t be done.
You can’t say “don’t change the value on wheel events but continue scrolling.”
You can only say “ignore the wheel events when that input has focus.”
And if you ignore the wheel events, you ignore both the value change and the
scrolling.
that would be a bit surprising. I've deal with (probably to much) script
and it can do just about anything if you set it up right
Wheel and Scroll events are 2 different things AFAIK
[…]
The point i was getting at is the inconsistency part not the default part.
Spaghetti code leads to inconsistency.
indeed
[…]
Now, AFAICT, to prevent the scroll thing to work on number inputs, you need to
disable the wheel event on the input element when it’s got focus. That can only
be done in Javascript (which is what handles events). And you need to be careful
not to disable scrolling altogether.
And then some people will find it annoying to have to click/move outside the
field before being able to scroll….
or just have it that scrolling works fine and you dont have to click/move out
to scroll. right now scrolling both scrolls the page and changes the input. they
could add some script so it just "blocks" it from changing the input
and it would still scroll
What I was trying to explain is that, as I understand it, it can’t be done.
You can’t say “don’t change the value on wheel events but continue scrolling.”
You can only say “ignore the wheel events when that input has focus.”
And if you ignore the wheel events, you ignore both the value change and the
scrolling.
that would be a bit surprising. I've deal with (probably to much) script
and it can do just about anything if you set it up right
Wheel and Scroll events are 2 different things AFAIK
Backing up a bit… I would argue that clicking the up or down button shouldn’t
give focus to the text box. Only clicking inside it should do that.
[…]
What it's doing today is:
* Click on up arrow once
* Immediately move cursor down
Sometimes the field changes to '1' and then to '0'.
Hi, I haven’t tried but what often happens is that when you give the focus to
a numeric field (= you type in it or change it), and then use the mousewheel,
then the mousewheel acts on the field (instead of scrolling).
You’re saying “move cursor down,” so I guess it’s not the mousewheel you’re using?
Or could your gesture could be understood as scrolling? Or maybe as a special
“gesture”¹?
¹ Gesture in this sense: “UX” people love to add magic shortcuts that the user
can trigger unknowingly….
[…]
What it's doing today is:
* Click on up arrow once
* Immediately move cursor down
Sometimes the field changes to '1' and then to '0'.
Hi, I haven’t tried but what often happens is that when you give the focus to
a numeric field (= you type in it or change it), and then use the mousewheel,
then the mousewheel acts on the field (instead of scrolling).
You’re saying “move cursor down,” so I guess it’s not the mousewheel you’re using?
Or could your gesture could be understood as scrolling? Or maybe as a special
“gesture”¹?
¹ Gesture in this sense: “UX” people love to add magic shortcuts that the user
can trigger unknowingly….
Oh, I bet that's it. Two-finger-swiping down on a trackpad to scroll the
page. I will need to be more careful in the future!
[…]
What it's doing today is:
* Click on up arrow once
* Immediately move cursor down
Sometimes the field changes to '1' and then to '0'.
Hi, I haven’t tried but what often happens is that when you give the focus to
a numeric field (= you type in it or change it), and then use the mousewheel,
then the mousewheel acts on the field (instead of scrolling).
You’re saying “move cursor down,” so I guess it’s not the mousewheel you’re using?
Or could your gesture could be understood as scrolling? Or maybe as a special
“gesture”¹?
¹ Gesture in this sense: “UX” people love to add magic shortcuts that the user
can trigger unknowingly….
Oh, I bet that's it. Two-finger-swiping down on a trackpad to scroll the
page. I will need to be more careful in the future!
Pay especially attention on the Order Refund page; it's easy to refund the
whole order if you scroll down close to the refund amount field... Really EASY.
[…]
Pay especially attention on the Order Refund page; it's easy to refund the
whole order if you scroll down close to the refund amount field... Really EASY.
[…]
Pay especially attention on the Order Refund page; it's easy to refund the
whole order if you scroll down close to the refund amount field... Really EASY.
OP is buyer only
And I'm a seller, so at the end of the day I'm tired.
You can't know this feeling of course.
USA, North Carolina
Canada, Ontario
France, Provence-Alpes-Côte d'Azur
Italy, Marche