Minor patch, but I was watching one of your videos on YouTube and
thought that the pop-up was unecessary/annoying in this case. Love
your enthusiasm for the project :^)
This patch makes it possible to call Node::invalidate_style() and have
that node and all of its ancestors recompute their style.
We then figure out if the new style is visually different from the old
style, and if so do a paint invalidation with set_needs_display().
Note that the "are they visually different" code is very incomplete!
Use this to make hover effects a lot more efficient. They no longer
cause a full relayout+repaint, but only a style invalidation.
Style invalidations are still quite heavy though, and there's a lot of
room for improvement there. :^)
This is currently very aggressive. Whenever the Document's hovered node
changes, we invalidate all style and do a full relayout.
It does look cool though. So cool that I'm adding it to the default
stylesheet. :^)
After we clear the FPU state in a thread when it uses the FPU for the
first time, we also save the clean slate in the thread's FPU state
buffer. When we're doing that, let's write through current->fpu_state()
just to make it clear what's going on.
It was actually safe, since we'd just overwritten the g_last_fpu_thread
pointer anyway, but this patch improves the communication of intent.
Spotted by Bryan Steele, thanks!
Replaced elements will now properly create line breaks when they use up
the available horizontal space.
This fixes an issue with <img>'s lining up instead of breaking.
Serenity is really not production ready; I shouldn't have to warn
you not to trust the RNG here. This is for compatibility with
software expecting the interface.
arc4random does expose an annoying flaw with the syscall I want
to discuss with Kling though.
The way it gets the entropy and blasts it to the buffer is pretty
ugly IMHO, but it does work for now. (It should be replaced, by
not truncating a u32.)
It implements an (unused for now) flags argument, like Linux but
instead of OpenBSD's. This is in case we want to distinguish
between entropy sources or any other reason and have to implement
a new syscall later. Of course, learn from Linux's struggles with
entropy sourcing too.
If you do a layout and it turns out that the page contents don't fit in
the viewport vertically, we add a vertical scrollbar. Since the
scrollbar takes up some horizontal space, this reduces the amount of
space available to the page. So we have to do a second layout pass. :^)
Fixes#650.
Cloned threads (basically, forked processes) inherit the complete FPU
state of their origin thread. There was a bug in the lazy FPU state
save/restore mechanism where a cloned thread would believe it had a
buffer full of valid FPU state (because the inherited flag said so)
but the origin thread had never actually copied any FPU state into it.
This patch fixes that by forcing out an FPU state save after doing
the initial FPU initialization (FNINIT) in a thread. :^)
We were leaking 512 bytes of kmalloc memory for every new thread.
This patch fixes that, and also makes sure to zero out the FPU state
buffer after allocating it, and finally also makes the LogStream
operator<< for Thread look a little bit nicer. :^)
When style is invalidated (for example when an external stylesheet
finishes loading) we delete the whole layout tree and build a new one.
This is necessary since the new style information may result in a
different layout tree.
When layout is invalidated (window resized, image dimensions learned,
etc..) we keep the existing layout tree but run the layout algorithm
once again.
There's obviously lots of room for improvement here. :^)
The layout root is now kept alive via Document::m_layout_root.
This will allow us to do more layout-related things inside the inner
layer of LibHTML without reaching out to the HtmlView.
I'd like to keep HtmlView at a slightly higher level, to prevent it
from getting too complex.
This patch also fixes accidental disconnection of the layout tree from
the DOM after doing a layout tree rebuild. ~LayoutNode() now only
unsets the DOM node's layout_node() if it's itself.
I was encountering an entire system crash when the window server
attempted to do something with the shortcut text on a submenu. This
bug only seemed to appear when I had a lone submenu inside of a menu.
These are basically copy and pasted from the regular string version.
Also add some more multi-byte/wide conversion stub.
libarchive wanted these. There's a lot more, but we can add them
one at a time.
This patch adds the CharacterData subclass of Node, which is now the
parent class of Text and a new Comment class.
A Comment node is one of these in HTML: <!--hello friends-->
Since these occur somewhat frequently on the web, we need to be able
to parse them.
This patch also adds a child rejection mechanism to the DOM tree.
Nodes can now override is_child_allowed(Node) and return false if they
don't want a particular Node to become a child of theirs. This is used
to prevent Document from taking on unwanted children.
The <br> element will produce a special LayoutBreak node in the layout
tree, which forces a break in the line layout whenever encountered.
This patch also makes LayoutBlock use the current line-height as the
minimum effective height for each line box. This ensures that having
multiple <br> elements in a row doesn't create 0-height line boxes.
We currently hard-code the line height to 140% of the font glyph height
and this patch doesn't fix the hard-coding, but at least moves it out
of LayoutText and into StyleProperties where it can be re-used until
the day we go and do a proper implementation of CSS line-height. :^)
This patch removes the hard-coded hack for "display: list-item" from
LayoutBlock and adds LayoutListItem and LayoutListItemMarker.
Elements with "display: list-item" now generate a LayoutListItem, which
may then also generate a LayoutListItemMarker if appropriate. :^)
For now this is simply a counter+hook exposed by ResourceLoader and
shown in the Browser status bar.
This is not very nuanced, and it would be nice to expose more info so
we could eventually do something like a progress bar.
This is obviously not ideal, and it would be better to teach it how to
allocate more pages, etc. But since the physical page allocator itself
currently uses SlabAllocator, it's a little bit tricky :^)
