| Age | Commit message (Collapse) | Author |
|---|
|
When an input element should not be displayed due to display:none, don't
allocate the Resource or the Embed directly. It won't be added to the
Widget tree either. This prevents allocating Resources that are not tied
to a Widget so they are not leaked when the tree is destroyed.
The Embed or Resource elements won't be needed as the DilloHtmlInput
handles all the form logic.
|
|
|
|
|
|
The display_none flag is only set _after_ the open tag has run, so it
will only affect child elements. If the current form input element has a
display:none itself, it should be also considered. The new function
a_Html_should_display() evaluates both conditions.
|
|
When the current element or a parent has display:none, the display_none
flag is set and no new element should be added to the viewport. For form
inputs, instead of always adding the Embed to the viewport, we only do
it if display_none is not set. The Embed is still registered as an input
in the form, so it will continue to send the proper form values to the
server.
For complex buttons that can contain nested elements inside, we switch
to a dummy button that doesn't have a Textbox and rely on the logic at
html.cc to avoid creating more child elements until the display_none is
unset.
Fixes: https://github.com/dillo-browser/dillo/issues/433
|
|
|
|
Instead of rejecting random characters that are not in the boundary
character set, draw a random index and select the character at that
position. The probability distribution is not perfectly uniform with
this method, but reduces the number of calls to rand() by 4 times on
average.
|
|
Makes it less likely that server implementations may break due to
unexpected boundary characters. It also allows us to avoid quotes
around the boundary.
|
|
Making the boundary string very unlikely to collide with the file to
upload allows Dillo to assume it would never be found and avoids the
expensive memmem() check.
Even if major implementations tend to add several '-' characters to
multipart/form-data boundaries, this is not enforced by RFC 2046, so it
can be increase to 70 random characters.
See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/VUB5PIOPJZ2VTCVGQPBZMGOYEISTXCFX/
|
|
The strdup function is not available in POSIX-2001, so we use our own
implementation in dlib: dStrdup.
Reviewed-by: dogma
|
|
Reviewed-by: dogma
|
|
|
|
|
|
|
|
|
|
|
|
We already have it that way for rows < 1, but not for when rows was not
specified.
|
|
|
|
I generally tried to:
- start with a capital letter.
- end with a period.
- put elements inside <>.
- bring element names close to the beginning of the message.
|
|
Now no extra line at the bottom of the bugs, plus shorter strings.
|
|
|
|
|
|
|
|
|
|
May happen with ill formed HTML.
|
|
|
|
|
|
|
|
dw::core::ImgRenderer, not dw::Image (which now implements the former) anymore.
|
|
|
|
|
|
...now that there's tel, url, email, datetime, date, month, week, time,
datetime-local, number, range, color (all of which I imagine we will
continue to regard as 'text').
|
|
This patch avoids a family of problems that arise from handling nested inputs.
from invalid memory access up to crashes.
e.g. details in bof-read-47_attachView.html.asan.
This patch is much wider than the above referred instance.
|
|
It is said that this is typically only useful when OPTGROUP is working
(OPTGROUP gives context, and label will be something shorter than the
OPTION's contents).
It is also said that browsers don't or didn't tend to use an OPTION's label.
*shrugs*
|
|
I wrote nearly all of this last year, and I've just been going back over it
now. As I recall, I initially also tried: select holds optgroups and options,
and optgroups hold options (instead of this flat array of options, optgroups,
and close-optgroups), but the code wasn't coming out any cleaner, so...
|
|
|
|
I was just looking at distrowatch, and noticed that a menu looked odd.
It turns out that their code goes like
Amarok Live<option value="amaroklive">Amarok Live</option>
Amber<option value="amber">Amber</option>
Ankur Bangla<option value="ankur">Ankur Bangla</option>
Annvix<option value="annvix">Annvix</option>
AnNyung<option value="annyung">AnNyung</option>
Anonym.OS<option value="anonymos">Anonym.OS</option>
for some crazy reason. This led to dillo showing labels like
"AnNyung Anonym.OS".
|
|
To fix box colors...
|
|
Unilaterally changing user data is consistently a bad idea, but when browser
users aren't given any idea what they are permitted to type, it's better than
leaving out the chars, or replacing with '?' or whatever.
|
|
|
|
As of a couple of years ago, there was talk and confusion over whether
rfc 2231 should be used, or rfc 2047. But now... *sigh*
|
|
|
|
This had been discussed a bit a few years ago. At the time, the html4 spec's
idea was that you probably should require one but that implementations varied
on the details.
These days, firefox doesn't, and html5 mostly tells you not to (and is clear
that you can deselect the only selected one). (The world's biggest document,
practically a browser written in english at the instruction level, and it
still has many cases that aren't considered and spelled out carefully at this
point.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
