Patent Application
20120311427
Electronic devices can receive content that is to be rendered for display. The received content can include electronic mail messages, web pages, social networking messages, or other content. A rendering engine of the electronic device is used to parse and layout the received content to produce an output that is capable of being displayed on a display device.
When a user attempts to view received content, such as by opening an electronic mail message, the rendering engine attempts to render the received content. In some cases, the content delivered to the electronic device is partial content, which may not properly be rendered by the rendering engine. In other cases, the content delivered to the electronic device can include a long segment that may take a while (e.g. a few seconds) to parse—during such parsing, nothing is shown by the rendering engine.
Some embodiments are described with respect to the following figures:
Rendering engines can be provided in electronic devices to parse and render content according to various defined formats. One example format is the HTML (Hypertext Markup Language) format, which is often used in electronic mail messages or web pages. Other formats can be used in other examples.
With HTML content (or content according to other markup languages), tags are used to assist a rendering engine (sometimes also referred to as a layout engine) in interpreting the content. Tags are elements used for annotating content (which can include text, images, and so forth). The tags can define the structure of the content (e.g., section heading, paragraph, title, line break, etc.) or an attribute of the content (font, color, style, etc.). Tags can also provide other instructions or definitions of content. Tags include opening tags and closing tags, where a pair of an opening tag and a closing tag defines an element, such as a text element, image element, or other element.
In certain scenarios, an electronic device may receive partial content from another device. For example, an electronic mail server device may deliver just a first portion of an electronic mail message to a client device, such as in cases where the content of the electronic mail message exceeds a certain size. As a result, the received partial content can include a fragment that contains an opening tag but that is missing a corresponding closing tag. Such a fragment is an example of an “unclosed fragment.”
Some rendering engines may be unable to properly render unclosed fragments. Upon receipt of an unclosed fragment, the unclosed fragment is not displayed as the client device awaits further content to be received. Thus, when a user attempts to open the partial content (such as a partial electronic mail message), the unclosed fragment is depicted as blank content until further content that contains the closing tag is received. In some cases, the further content may not be delivered until a user performs an action to request more content.
In other scenarios, a client device may receive content that includes a relatively long text element (or other type of element). As the relatively long text segment is received by the client device, the parser of the rendering engine may take a relatively long time (e.g., a few seconds) to parse the long text element. While the rendering engine is parsing the text element, the user may see a blank portion where the text element is supposed to have been rendered. This can have a relatively jarring effect on the user when the user is initially retrieving content, such as opening an electronic mail message or other content. A relatively long element (such as a text element) that is in the process of being parsed by a rendering engine is also referred to as an “unclosed fragment.”
More generally, an “unclosed fragment” refers to any portion of content that is to be rendered on a client device, where the portion does not contain a closing tag that corresponds to an opening tag in the portion. The portion can be partial content sent by a server device to a client device, where the partial content is missing further data not yet sent by the server device until a further event occurs, such as when a request for more content is submitted by the client device. The portion can also be part of full content that has been received by the client device, but the portion has a length that exceeds some predefined length threshold that can result in delay in display of the portion while the portion is being parsed by a rendering engine.
In accordance with some embodiments, to allow for proper display of an unclosed fragment in received data, a “benign tag” is inserted into the unclosed fragment. A “benign tag” (which can also be referred to as a “dummy tag”) refers to a tag that has no operational meaning to the rendering engine. In other words, from the perspective of the rendering engine, the benign tag (or dummy tag) is not a tag defined by the respective standard or protocol and thus does not provide any instruction to the rendering engine regarding how to render received content. In implementations where the content is defined by a markup language such as HTML, the benign tag is a tag not defined by the markup language.
Examples of the client device 100 include a computer (e.g. desktop computer, notebook computer, tablet computer, and so forth), a personal digital assistant (PDA), a mobile telephone, an electronic appliance or other type of electronic device.
The server device 102 can be any electronic device that is able to communicate data to the client device 100. Examples of the server device 102 include an electronic mail server (that communicates electronic mail messages to client devices), a web server device, a proxy device, and so forth. The server device 102 can be implemented with a server computer or a system having multiple server computers, as examples.
The client device 100 includes an application 104 which is able to receive data from the server device 102 and to display the data on a display device 106 of the client device 100. For example, the application 104 can be an electronic mail application to present electronic mail messages in the display device 106 of the client device 100. In other implementations, the application 104 can be a web browser (to display web content), a social networking application (to display social networking messages), or any other type of application that allows a user of the client device 100 to view content in the display device 106.
The client device 100 also includes a rendering engine 108 that processes content received by the application 104 to allow the received data to be displayed in the display device 106. In some implementations, the content is defined by a markup language such as HTML. In some examples, the rendering engine 108 can include a parser 108A to parse received content, a layout process 1088 to place various nodes representing different parts of the received content in a layout as the respective parts of the content would appear in a display, and a painter 108C to paint the content according to the layout specified by the layout process 1088.
In some examples, the rendering engine 108 can be a WebKit rendering engine, which is an open source rendering engine used for rendering web pages. In other implementations, the rendering engine 108 can be another type of rendering engine.
In accordance with some embodiments, the application 104 contains fragment processing logic 110, which is able to process a received unclosed fragment to allow for proper display of the unclosed fragment. Although the fragment processing logic 110 is depicted as being part of the application 104, it is noted that in alternative implementations, the fragment processing logic 110 can be external to the application 104, but can be invoked by the application 104 to process unclosed fragments in accordance with some embodiments.
As shown in
As further shown in
Next, the fragment processing logic identifies (at 204) a fragment in the data that is unclosed. Identifying a portion of received data as being an unclosed fragment can be in response to determining that a condition is satisfied. The condition can be that an indication has been received by the fragment processing logic 110 that the received data is partial data that is missing further data not yet sent by the server device 102. Such indication of partial data can be indicated by a “more” break, which is an indication that there is further data not yet sent by the server device 102. The further data is not sent by the server device 102 until the client device 100 sends a request for the further data, such as in response to user action at the client device 100 (e.g. user selecting a selectable link or icon or performing another action to request that the further data be sent).
Alternatively, another condition indicating that the portion of the received data should be identified as an unclosed fragment is that the portion has a length (e.g. expressed as a number of text characters) that exceeds a length threshold. A data portion having a length that exceeds the length threshold may take a while (e.g. several seconds) for the parser 108A of the parsing engine 108 to parse, during which time the data portion cannot be rendered by the rendering engine 108.
If an unclosed fragment is identified, then the fragment processing logic 110 inserts (at 206) a benign tag in the unclosed fragment to cause a rendering engine to render the unclosed fragment. Note that the insertion of the benign tag is at a position that is not within another tag or an entity (discussed further below).
In some implementations, the unclosed fragment depicted in
In response to detecting presence of the benign tag, </x>, the rendering engine 108 processes the fragment shown in
After rendering the text in the fragment shown in
As noted above, in some scenarios, an unclosed fragment can be a fragment including a portion of content that exceeds a predefined length threshold. To detect such condition, the fragment processing logic 110 is configured to count a number of characters in the received data.
The fragment processing logic determines (at 506) if the count of the number of characters exceeds a length threshold. If the count exceeds the length threshold, then the fragment processing logic 110 identifies (508) the received data portion as an unclosed fragment. In response to such identification, the fragment processing logic inserts (at 510) a benign tag in the unclosed fragment (at a position of the unclosed fragment that is not within another tag or an entity, as discussed further below).
However, if the count of the number of characters does not exceed the length threshold, as determined at 506, the fragment processing logic 110 determines (at 512) whether a “more” break has been encountered. The “more” break is provided at the end of a first section of data (as sent by the server device 102) has been reached—the “more” break is an indication from the server device that there is further data not yet sent by the server device. Upon detection of the “more” break (or some other indication that the received data portion is partial data that is missing further data), the fragment processing logic 110 proceeds to tasks 508 and 510, to identify (508) the received data portion as an unclosed fragment and to insert (510) a benign tag in the unclosed fragment.
If a “more” break is not detected (at 512), then the fragment processing logic 110 determines (at 514) whether a closing tag (corresponding to the opening tag from which the fragment processing logic 110 started the count of characters) has been encountered. If not, then the process continues (at 502). However, if a closing character has been encountered (514), then the procedure of
As noted above, when inserting a benign tag, care is taken by the fragment processing logic 110 to ensure that the benign tag is not inserted in another markup language tag or inside a markup language entity. For example,
When a benign tag is to be inserted, the benign tag should not be inserted in either the tag <em> or </em>, or inside the entity &.
However, if another tag or entity was found, the fragment processing logic 110 identifies (at 706) a position before or after the other tag or entity. The benign tag is added (at 708) at this identified position.
To speed up the search for another tag or entity, the data portion can be scanned from its end. The search is sped up since only the last unclosed fragment has to be parsed by the fragment processing logic 110 to check for tags and entities. The ability of the fragment processing logic 110 to look for tags and entities to avoid inserting benign tags into such tags or entities assumes that the content is well-formed (meaning that the tags all match up, quotes all match up, and so forth).
In alternate implementations, instead of scanning the unclosed fragment to find another tag or entity, the fragment processing logic 110 can instead interact with the parser 108A (
When the parser 108A encounters a “<” character, the parser 108A changes its state to “Tag open state.” If the fragment processing logic 110 determines, based on querying the parser 108A, that the parser 108A is currently in the “Tag open state,” then that is an indication that a benign tag cannot be inserted at the current position, as doing so would mean that the benign tag is inserted within another tag. The parser 108A stays in the “Tag open state” until the “>” character is consumed by the parser 108A, at which time the state of the parser 108A changes back to a “Data state.” The parser 108A encountering the “&” symbol would also cause the parser 108A to change its state from the “Data state” to a state that the parser 108A is parsing a markup language entity.
In accordance with some implementations, a fragment processing logic 110 is able to insert a benign tag when it receives a response from the parser 108A that the parser 108A is currently in the “Data state.” However, if the state returned by the parser 108A is a state indicating that the current position of the parsed content is within a tag or an entity, then the fragment processing logic 110 avoids inserting the benign tag.
By using techniques or mechanisms according to some implementations, unclosed fragments of received content can be properly rendered to enhance the user viewing experience.
Machine-readable instructions of modules described above (including the application 104, fragment processing logic 110, and rendering engine 108 of
Data and instructions are stored in respective storage devices, which are implemented as one or more computer-readable or machine-readable storage media. The storage media include different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic media including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternatively, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple components. The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.
In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some or all of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.
