When using Chrome DevTools to perform a memory snapshot on a page with a DIV with 2 children, a SPAN and an A. I hold the A tag in memory by saving a reference in a variable, then remove the DIV from the DOM. Here is the DOM Tree before removing the DIV
When I do a snapshot, and look at one of the Detached HTMLSpanElements, in the Retainers it shows a Detached HTMLAnchorElement, with the number [7]. Here is the snapshot
What do the numbers to the left of DOM nodes mean?
From playing around I've noticed it seems [5] means it's the child, [6] means it's the parent and [7] means it's a sibling. I have also seen other numbers occasionally, and would like to know if it's documented anywhere what these numbers mean?
Related
I am using GWT's (2.5) SimplePager class in my application, to display pre-loaded data (I know the exact row count in advance).
The issue is with the last page. Given I have, for instance, 42 elements with an initial visible range of 10.
First page is 1-10, second 11-20, third 21-30, fourth, 31-40.
The issue is that fifth page is not 41-42 (which I want, because I want to be able to scroll back and forth and "land" exactly on the same data) but 33-42.
I have tried various tinkering with overriding SimplePager / AbstractPager methods, with no success.
For instance, if I override setPageStart, do the same as com.google.gwt.user.cellview.client.AbstractPager.setPageStart(int) but with the following commented out (I think it is the culprit code):
if (isRangeLimited && display.isRowCountExact()) {
index = Math.min(index, display.getRowCount() - pageSize);
}
The last page is fine (41-42), but this erases page size forever and when I go from last page to previous page, it becomes 40-41 (expected: 31-40). This is probably because the page size is not some constant provided to the pager instance, but is calculated with the Range object which was last used ("int pageSize = range.getLength();" in setPageStart method).
Any clue on modifying the paging behavior to my needs without breaking anything ?
Thanks !
I eventually got a working solution which is simple enough.
I provided a page size (which is the maximum number of elements that could be displayed, regardless of the total number of elements available to display) to my SimplePager object. Then I overrided getPage(), hasNextPage(), hasNextPages(int), hasPreviousPages(int), nextPage(), previousPage(), setPageStart(int) to use the provided page size instead of getLength() on the Range object.
To test this more easily (still done by hand...) I used GWT's Showcase project (and ran it in dev mode).
The downside is that I had to copy the code of the overriden methods (from AbstractPager - SimplePager does nothing except calling the superclass' methods) into my Pager class.
Having a infinite scroll (with new items loaded by remote calls) together with collection repeat and items of different size, I have an issue that after new batch of item is renedered, the scrollbar "jumps" to the middle, or to explain it other way around, it is not on the bottom where it should be (on the button but moved a bit back to accomodate for the new items).
The most probable issue is that
this.$scope.$broadcast('scroll.infiniteScrollComplete');
is called BEFORE the items are added to the array / rendered.
One easy way to do this is if items are added as a result of a promise, but $broadcast is done before the promise is completed.
solved this by setting item-render-buffer property of collection-repeat
<div collection-repeat="business in businesses" item-height="120px" item-render-buffer="10"></div>
Following this question I have recently asked : Understanding Document.createElement()
Here is the context :
There is a text-zone in my GWT GUI that holds a text
Users can select a word (or a sequence of words) in this text-zone and transform it / them into a highlighted text
highlighted texts need to be able to listen to users : click, right-click, dragging & dropping operations
A scenario with 1000 highlighted text in the text-zone is not impossible.
I was wondering :
Is it a bad approach to manipulate DOM elements directly in GWT ? (Without using Widgets)
Is it a bad approach to do things like that Add listener to SpanElement ? Can it cause memory leaks ?
What is the best approach to achieve such things ? I've done some tests with a simple custom widget that uses a span element, and adding 1000 widgets to the RootPanel takes approximatively 6 to 10 seconds in DevMode. When I use DOM elements direclty, this operation duration goes under 1 second (even less than 200ms with optimizations).
EDIT
Performance should not be a problem, according to some real tests I did after #Gilberto advices. http://jmichelgarciagwt.appspot.com/DOMTesting.html
Still, I would love to have feedbacks for questions 1) and 2)
Adding listeners/handlers to hundreds of span elements/widgets is definitely a bad approach.
If you stay with GWT, you can attach a single event handler to your "text zone" widget, and then find which element has been the source of the click:
http://comments.gmane.org/gmane.org.google.gwt/61911
If you go with DOM elements, you can attach a single event listener to your "text zone" element and find out the event source when it bubbles to it. For example:
http://icant.co.uk/sandbox/eventdelegation/
As the title states: Will focus still be set on form controls with autofocus="autofocus" even if they are hidden with display: none; or visibility: hidden;?
If your question is whether a hidden field can steal autofocus from a visible one, the answer is no.
Hidden fields with an autofocus property get focus when they are made visible.
Here's a jsFiddle that shows what happens if you have a visible field and a hidden field, then show the hidden field.
And here's a variation that demonstrates what happens if the visible field does not have an autofocus property.
The HTML5 draft standard only requires that an element be "focusable" where focusable means:
An element is focusable if the user agent's default behavior allows it
to be focusable or if the element is specially focusable, but only if
the element is either being rendered or is a descendant of a canvas
element that represents embedded content.
User agents should make the following elements focusable, unless platform conventions dictate otherwise:
a elements that have an href attribute
link elements that have an href attribute
button elements that are not disabled
input elements whose type attribute are not in the Hidden state and that are not disabled
select elements that are not disabled
textarea elements that are not disabled
command elements that do not have a disabled attribute
Elements with a draggable attribute set, if that would enable the user agent to allow the user to begin a drag operations for those
elements without the use of a pointing device
Editing hosts
Browsing context containers
It does say "but only if the element is either being rendered..." and the standard defines "rendered" as:
An element is being rendered if it is in a Document, either its parent
node is itself being rendered or it is the Document node, and it is
not explicitly excluded from the rendering using either:
the CSS 'display' property's 'none' value, or
the 'visibility' property's 'collapse' value unless it is being treated as equivalent to the 'hidden' value, or
some equivalent in other styling languages.
Just being off-screen does not mean the element is not being rendered. The presence of the hidden attribute normally means the
element is not being rendered, though this might be overridden by the
style sheets.
User agents that do not honor author-level CSS style sheets are nonetheless expected to act as if they applied the CSS rules given in
these sections in a manner consistent with this specification and the
relevant CSS and Unicode specifications.
In short, the answer appears to be that if all other requirements are met then display:none won't be focused but display:hidden will - Assuming all browsers actually follow the spec.
I am working on a new project and I am using Joomla version 1.5.22.
I need to display one horizontal search form in the middle of home page and the same search form in vertical style in all other pages but in left position.
So what I did is, I created two template files one for horizontal search(horizontal.php) and other for vertical search (vertical.php) and in mod_modulename.php I tried to load the respective modules based on a certain condition and changed the position left or middle according to it. The positions are changed in the database to get effected in the admin panel.
if(condition) {
modModulenameHelper::changeToVertical($position);//to change position in database to left
require( JModuleHelper::getLayoutPath( 'mod_modulename', 'vertical'));
}
else {
modModulenameHelper::changeToHorizontal($position);//to change position in database to middle
require( JModuleHelper::getLayoutPath( 'mod_modulename', 'horizontal'));
But I am not getting the correct output. It is loading the respective modules based on the condition. But the position is not assigned at first. And if I press Ctrl+F5 or refreshes, the page will be loaded with the desired output.
Why is this happening? Any Solution??
The problem is that you are changing the position after the fact. By the time you are changing the position, Joomla has already assigned the module to a position. It's an order of operations thing.
Instead, why not just use 2 instances of the module? Rather than going through this trouble, simply add a parameter to the module that allows you to select horizontal or vertical, then assign one to the home page menu item and another to the rest of the pages. This would also allow for putting the module in other positions instead of hard coding it in to the module.