| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Previously, aborted HTML fetches left the content in LOADING state,
and the hlcache clean code does not clean contents in the LOADING
state. They, and their child contents ended up stuck in the
cache forever.
|
| |
|
|
| |
This makes it easier to track a content by its ID through a log.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were handling the STYLE tag getting added in the
dom_default_action_DOMSubtreeModified_cb callback, however,
the media attribute dadn't been added by that point.
We now check it in the dom_default_action_DOMNodeInserted_cb
callback, at which time the media attribute is available for
checking.
Note, we should probably store the media type in the
html_stylesheet structure, but for now we just have an
`unused` boolean.
Also, it may be possible to optimise to avoid parsing non-
screen media STYLE element data if we could detect the media
earlier.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This refactors the core "font" sizing API to be handled through gui
function tables similar to every other core/frontend calling API.
|
| |
|
|
|
| |
split out the string handling API from the rest of the utils header
and fix up all the fallout.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
An alternative approach which may be better would be to create the
JavaScript context when the html_content is created, rather than
on demand.
This code checks for the JS context and creates one every time we
add a node to the DOM. So when JS is on, every doc with a single
node in it has a JS context. This seems to make on-demand creation
a redundant overhead.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we take the value of the javascript_enabled option when the
content is created. We then use the content's script_enabled
boolean everywhere else.
This prevents us getting inconsistent values for javascript_enabled
if a user toggles the setting while a page is loading.
It was read frequently during box construction, and also the
parser's script enabled setting could change where we handled
a change of encoding.
Now we only care about the setting of the javascript_enabled
option at time of html_content creation.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The semantic patch tool appears to have missed some difficult to
reason about callsites which have now been manually cleaned up
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This changes the LOG macro to be varadic removing the need for all
callsites to have double bracketing and allows for future improvement
on how we use the logging macros.
The callsites were changed with coccinelle and the changes checked by
hand. Compile tested for several frontends but not all.
A formatting annotation has also been added which allows the compiler
to check the parameters and types passed to the logging.
|
| |
|
|
|
|
|
|
| |
The ftell call in the html renderer handling of drag and drop was not
checking its return value for errors which could have resulted in
attempting to read -1 bytes.
coverity 1251038
|
| |
|
|
|
|
|
|
|
|
| |
The html content script handling needs to invalidate its JavaScript
context when the browsing context (browser_window) containing it is
either closed or the content fetch is aborted (stopped)
Previously the invalidation was only done on browser_window close
which resulted in use after free crashes because of the now invalid
JavaScript context.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When the browser window is about to be destroyed html_close gets
called indicating the browser_window previously associated with the
html content is about to become invalid.
This makes the javascript context invalid within the html content (it
is held by the browser window) when that context is about to be
destroyed. Previously the javascript children would continue to
attempt to use the context after it had been destroyed causing all
sorts of strange errors and failures.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Very little of the form API needed exposing outside of the
renderer. This makes the form API that may be used by frontends
obvious and limited.
|
| | |
|
| |
|
|
|
| |
Extend the content_get_encoding() API to retrieve the source of
the encoding as well as the actual encoding.
|
| |
|
|
|
|
|
|
| |
Previously content handler debugging features were accessed by global
variables. This allows the setting of debugging parameters via a
content API giving per content control over debugging features.
Currently only used by the html content handler to toggle global
redraw debugging.
|
| |
|
|
|
|
|
| |
The frontends previously had to use an html renderer API to get the
encoding of a content. This also required the explicit checking of the
contents type rather than using the existing content API to abstract
this knowledge.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Update the API which allows frontends to acquire the page features
(images, link urls or form elements) present at the given coordinates
within a browser window.
By making this an explicit browser_window API and using the browser.h
header for the associated data structure with a more appropriate API
naming the usage is much more obvious and contained.
Additionally the link url is now passed around as a nsurl stopping it
being converted from nsurl to text and back again several times.
|
| | |
|
| |
|
|
| |
Second in the series to decouple the core API usage from the frontends.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The netsurf core is driven from numerous operation tables most of
which are now set through a common netsurf_register() interface. The
font and plotting interfaces are currently separate and unlike all the
other operation tables are modified for differing contexts.
This change moves the font operations alongside all the other
operations table and remove unnecessary interaction with the renderers
font internals. Further this also removes the need for css internals
to be visible in frontends.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
