Is there any way to access the render tree (or the DOM and CSSOM trees) of a page -- programmatically -- before being processed by the rendering engine, in Chrome?
And, ideally, could this be achieved through a Chrome extension, (with any combination of Javascript and/or C++ interfacing with the browser itself)?
Also, this may not be particularly the same but you can see the sequence of the page construction via Chrome dev tools. This is possible by recording the page in the timeline which provides a detailed list of the steps taken to render the page. It is a very extensive list and useful if you would like to take a deeper look. Hope this helps :)
Related
Problem
So we have quite a big project with lots of different Partial Views and a client side data binding framework (Knockout.js in our case).
One of the more problemtic parts is that is getting harder and harder to figure out which partial view is rendering an element that I see on my page.
So I need to debug this particular DIV. Okay, where do I find it?
Usually I try to find a very specific class or ID close by this element and do a search through the whole platform - far from ideal.
Question
So I was thinking about the following; tagging all elements (in debug mode) with the source file where they have been generated.
Right now I'm thinking about something like a precompiler that adds a data-source="" to every element. I might refer to an ID within a dictionary to prevent repeating all the long filenames.
Before I'm reinventing the wheel:
is there already something similar?
are there better alternatives?
We're using ASP.NET MVC, but any hints to how other platforms do this are perfect too.
If you are using Visual Studio, I highly recommend the Web Essentials extension. Among many great features, it has one called "Inspect Mode", part of the larger "Browser Link" feature, that does exactly what you are looking for; it identifies the file that a particular DOM element came from. It might be worth a shot if that option is open to you.
#Dirk, as per my understanding your issue is to easily identify the element/view. Adding data-source can be an option but before that have a look at this link
Editing Styles and DOM - Chrome Dev Tools
This page has many demonstrations which might be helpful to your problem. Furthermore, I do agree with Kevin suggestion.
First, a short disclaimer. I have next to no knowledge about web applications. I come from an iOS background where I exclusively wrote native code, so if you write your answers like I know nothing outside the shallow parts, that would be great.
I'm interested in learning a stack to develop web applications, but I'm not sure what the right way to build the GUI is. I know that a web front end consists of html and CSS to create the display and javascript as the bridge between the back end and the GUI, but I don't know the best way to put something together.
I know in iOS, you can use the Interface Builder (part of xcode that lets you graphically create the xml that describes the display) to create GUI's without any knowledge of how iOS translates the xml to some rendering, or even what is written in your xml files. Is there any analog to the web front end?
I'm mainly just looking for a list of the accepted ways to develop the GUI for a web application. If I have to learn HTML and CSS, so be it, but I'd like to know what my options are and the tradeoffs between each of them.
I can answer shortly stating that (technically) you can design web pages without coding in HTML or CSS, or even Javascript - although, you would be somewhat limited in your creative abilities and applications.
You can read about WYSIWYG html editors on this link, or try out ckeditor (someone said it's good)...
...I think a bit of background will help you reach a correct decision...
so here goes:
The Long Answer
I would start by trying to put the world of web programming and design into concepts that correlate with iOS coding.
If we look at the whole of a web app from an MVC perspective, then the browser is the view, the server is the controller and the database is the model... although this is very simplified.
Just like in iOS, each of these can be (but doesn't have to be) broken down into sub-MVC systems.
Just like any model in MVC, the view (the browser) can talk to the model (the database), but really it shouldn't. that's just bad practice.
If we break down the main-view (the browser) to a sub-MVC system, I would consider the HTML as the model, the CSS as the view and the browser (through links and javascript) as the controller.
It's not all that clear cut, but thinking like this helps me practice better and cleaner coding.
The HTML is the view's model for the web-app - it contains the data to be displayed or used.
HTML is a variation on the XML format and it contains data organized in a similar way to an XML file.
The basic HTML file will contain:
<html>
<head>
</head>
<body>
</body>
</html>
this should look familiar to you if you read any XML.
The CSS (cascading style sheets) is the view - it states HOW the html DATA should be displayed.
if your web app does't have any CSS, it will use the browser's default CSS/styling to be applied on the data in the HTML.
This "language" makes me think more about dictionaries in iOS (I think that's what they're called in Objective C). They have properties and values (like key-value pairs) that determine how the HTML data is displayed (if it's displayed).
They could look something like this:
body
{
color: white;
background-color: black
}
The browser is the web-app's view's controller - it makes it all work together and serves it up to the screen.
Javascript and links help us tell the controller what we want it to do, but it is the browser that acts (and willfully at times).
You can have a whole web app that acts without javascript, using only the default actions offered by links - in which case the browser will usually ask the server (the main controller) what to do.
Javascript helps us move some of the legwork from the server to the client, by allowing us to have a "smarter" controller for our view - just like in iOS.
The issue of the errant main-view / browser
Not all views are created equal, and not all browsers are the same.
Because the browser is used as the controller for the web-app's view, and because some browsers act differently then others, we web coders have the problem of working around someone else's idea of how our view's controller should behave.
You might see us complaining about it quite a lot (especially complaining about Internet Explorer).
These days, this issue is not as big of a problem as it used to be... it's just that some people don't update their computers...
WYSIWYG web editors
There are website builders and editors that try to work like X-Code does, by allowing us to build the website much like we would write word documents.
But, unlike X-Code which codes only the graphical interface of the view, these website builders write the model as well and usually add javascript into the mix.
When we use these tools (which I avoid), the whole MVC model breaks apart.
We can use them as a starting point for dirty work, but then we take their code apart and adjust it to our needs - usually by taking the code we need for the view (CSS) and applying it where we need it (and discarding much of the nonsense they add to the code and the HTML).
To summarize
As you can tell, HTML and CSS (and Javascript) are only a small part of a web app - as they all relate to the main view of the web app.
To write the controller and models for web apps, we use other tools (such as Ruby, PHP, js.node, MySQL and the like).
Coding the HTML and CSS isn't as hard as you might think, although it might be harder then I present it to be.
You can avoid writing code for web apps and use applications that offer WYSIWYG (What You See Is What You Get), but that would limit your abilities and will take away from your control over what you want to create.
According to
http://www.chromium.org/developers/content-module
The "content" module is located in src\content, and is the core code
needed to render a page using a multi-process sandboxed browser. It
includes all the web platform features (i.e. HTML5) and GPU
acceleration. It does not include Chrome features, i.e.
extensions/autofill/spelling etc. The goal is that any embedder should
be able to build a browser by starting with content, and then pick and
choose Chrome features.
content vs chrome As discussed above, content should only have the
core code needed to render a page. Chrome features use APIs that are
provided by content to filter IPCs and get notified of events that
they require. How to Add New Features (without bloating
RenderView/RenderViewHost/WebContents) describes how to do this.
As an example, here's a (non-exhaustive) list of features that are
Chrome only, and so are not in content. This means that content code
shouldn't have to know anything about them, only providing generic
APIs that they can be built upon.
Extensions
NaCl
ChromeFrame
SpellCheck
Autofill
Sync
Prerendering
Safe Browsing
Translate
Is WebRTC included in Chromium-Content module?
I am not sure, especially, finding jingle directory is outside of content.
Thanks
The webrtc project is included in the <chromium>/src/third_party/webrtc directory.
If you are asking if the components are used in the content_shell target, yes they are. You have access to all the same features with regards to webrtc that you would have in Chromium proper.
Is it possible for one to hook onto / access and edit a webpage's contents (like in the inspect element feature) live in chrome using .NET? Can this be done discreetly in the background as well. I don't have any malicious intentions, just creating a simple hack for a game online that relies on its HTML sourcing.
You can use a headless browser like Selenium to do this, they provide an easy .NET library that allows you to interact with a browser programmatically. Also, points for being aware that the question sounds suspicious.
I would like to know if it is possible to modify Chrome or Firefox display settings, so that it would only show rectangles of HTML DOM objects? What I want to do is to decrease rendering engine job amount as much as possible, so it would only build layout of the page.
People usually refer to this mode of operation as "headless" (i.e. without UI).
Usually there's an additional requirement - to be able to run it server-side without the usual for client software installed. If you're running it client-side, I wouldn't bother about optimization, it shouldn't give you a big win anyway.
Otherwise, try searching using that term. I've seen it asked for several times, but haven't seen a working out-of-box solution.
[edit] just saw http://hg.mozilla.org/incubator/offscreen, which seems to be a headless version of Mozilla.
I wouldn't go as low-level as modifying the renderer. Instead, I suggest you use Firefox's Greasemonkey to replace the elements from the page with whatever it is you need. You'll need to know a bit of JavaScript, but it's not that hard.
However, this will only work on client side. If you want to do this on server-side ( so that it will work on any page a user requests through your own ), my guess is you'll need to grab the page's content in a string, and then modify it using a HTML parser.