Google knows what you want
-
I wonder if ask those other websites are also unusable on EDGE or if Ducksauce has the monopoly...
-
I wonder if ask those other websites are also unusable on EDGE or if Ducksauce has the monopoly...
Got a bug report in this week. I think Edge has some special snowflaking going on in regards to the back button. User fills out a form, clicks SUBMIT, then back, and the form may or may not be populated when they return. Caveat being this is a slightly older version of the website, so it's SLIGHTLY possible we have some dumbfuckery going on in the code. But I'm not giving Edge the benefit of the doubt.
Also, there's a chance it's not submitting values for INPUT or SELECT elements that are disabled.
-
@Lorne_Kates said:
Also, there's a chance it's not submitting values for INPUT or SELECT elements that are disabled.
Isn't that a standard HTML thing? I know when I disable aninput
in Chrome the value doesn't get submitted.
-
@Lorne_Kates said:
Also, there's a chance it's not submitting values for INPUT or SELECT elements that are disabled.
Isn't that a standard HTML thing? I know when I disable aninput
in Chrome the value doesn't get submitted.I want to say "yes and no and maybe". A bunch of sites I've worked on disabled elements that were read only. Like, if the Country list only has one possible selection (because these items only ship to the USA), it'll show only that item, and grey out the input. But will still take the value from the POST.
Maybe that's non-standard, and suppressing the value in POST is correct. Dunno.
-
@Lorne_Kates said:
Maybe that's non-standard
they're probably stuffing in a hidden input with the only possible value. it's what i do when i have to have a disabled field in my form.
@Lorne_Kates said:
and suppressing the value in POST is correct.
it is. source (no there isn't an anchor tag i can select to get you closer..... curse you MDN and your lack of anchor tags!)
-
That's why you have both
disabled
andreadonly
attributes on mostinput
elements.
-
it is. source (no there isn't an anchor tag i can select to get you closer..... curse you MDN and your lack of anchor tags!)
Noted. And no, there's no accompanying hidden input field, unless .Net autogenerates one. It might. And then whatever validation is being used to ensure there's a value in that element is wrong. Or not.
Fucking web standards and hacky 10 year old code base.
-
@Lorne_Kates said:
Maybe that's non-standard
they're probably stuffing in a hidden input with the only possible value. it's what i do when i have to have a disabled field in my form.
If the field is disabled, shouldn't the server already know what the only possible value for it is?
Usually, I mean... unless your Javascript front-end is really in charge.
-
it is.
Hixie loves anchor tags.@Lorne_Kates said:Noted. And no, there's no accompanying hidden input field, unless .Net autogenerates one. It might. And then whatever validation is being used to ensure there's a value in that element is wrong. Or not.
In Web Forms, .NET autogenerates one called "__VIEWSTATE", so as long as client-side JS isn't mucking with what's in disabled fields, the fields or the page or the app don't have that view state disabled, some numbskull isn't doingFucking web standards and hacky 10 year old code base.
Response.Redirect()
and throwing it away, the guy doing the checking is doing it during Load and not Init, and the guy doing the checking is doing it via the controls and notRequest.Form[]
, you should be able to get that value.ETA: Oh, and whoever's setting it can do so no later than PreRender, and if they set it during Init but the view state has a different value, the view state's value gets set just before Load. And the only reason I remember any of this was because it was a job interview question.
-
For bonus points, slightly further down:
4.10.22.6 URL-encoded form data
Note: This form data set encoding is in many ways an aberrant monstrosity, the result of many years of implementation accidents and compromises leading to a set of requirements necessary for interoperability, but in no way representing good design practices. In particular, readers are cautioned to pay close attention to the twisted details involving repeated (and in some cases nested) conversions between character encodings and byte sequences.
-
If the field is disabled, shouldn't the server already know what the only possible value for it is?
Depends on why it's disabled
-
If the field is disabled, shouldn't the server already know what the only possible value for it is?
yep.
and if it was an external facing app i would have more protections in place. but i kept it simple for this one.
This is an internal app with no external facing components, so if they mess with it it's their fault their data is bad.
-
It's disabled because the application doesn't care to know whatever value the user might have otherwise wanted to put in it.
-
When I said EDGE I meant this: https://en.m.wikipedia.org/wiki/Enhanced_Data_Rates_for_GSM_Evolution
Yeah, due to downloading megabytes of shitty JavaScript frameworks (as if there were any other ones) it is a massive pain in the ass to say the least...
-
-
That doesn't look like any Google ad I've ever seen. Are you sure the "powered by Google" heading was related to the ads?
-
Yes...? It was one of those "suggested content" things.
-
Google owns DoubleClick, one of the two largest ad exchanges around. (Facebook owns what used to be called Atlas, the other one.)
They "power" a lot of ads.
-
-
That's a hedgehog, not a @Fox.
-
Any element with an id can be made into a target?
-
no there isn't an anchor tag i can select to get you closer
Any id appears to suffice - it doesn't have to be an anchor id. (At least on Firefox and Chrome.)
-
-
Tried looking for a cite but my google-fu isn't working today...