Is there a way to make firebug (or any other browser, or using any other tool) stop any dom manipulation from happening? Sometimes layout debugging a screen filled with on hover events is impossible, as the elements may disappear, and you can't see their compound layout.
I freeze DOM Manipulation in FF with Firebug clicking right button on Node and set "Stop when add/change child"
Actually this is quite easy to do for pages that are not constantly and autonomously being altered (even comet applications can be relatively stable for a few seconds): just save the page using firefox. It will save the current state of it all, ignoring all javascript and events. More than that, the styles will be easily viewable.
i wish there was a better way to do this, i wonder if it would be possible to do with a bookmarklet, im surprised theres no button in firebug or chrome to just freeze the dom, or is there one, that i dont know about?
Related
Background:
When focused on a WebView control, TalkBack announces something to the effect of "Bing. WebView. Double tap and hold to long press" (note that focus is on the WebView control itself, not the content within the webview). However, as best I can tell, double tap and long pressing doesn't seem to do anything other than pass TalkBack focus into a control within the WebView itself. Our team has testers that specialize in accessibility which filed a bug on us for this "Double tap and hold to long press" announcement. The rationale within the bug states that since this action doesn't appear to do anything, the announcement will only serve to confuse TalkBack users.
This announcement doesn't appear to be specific to our app as I was able to reproduce this behavior on a new, blank Android app with a WebView that points to Google (there it announces "Google. WebView. Double tap and hold to long press"). As I think it helps show what focus I'm talking about, I have added a screenshot of the prototype app I built with the green TalkBack focus indicator below:
Questions:
Is there a reason for why Android insists on announcing the "double tap and hold to long press" piece for a WebView? If there is a functional reason for this, then any attempt to fix this issue may be moot.
Does anyone know of a way to stop TalkBack from reading the "double tap and long press"? Alternatively, is there a way to hide the WebView control itself from TalkBack without hiding the html content within?
What I've tried:
Unfortunately saw no luck setting isLongClickable to false, setting empty onLongClickListeners, and worked with a few of the suggestions in the stackoverflows here, here, here, and here. I tried all of the mentioned changes on a blank app to reduce the possibility that the complexities of our production app has interfered with the experiments I was running. Setting the ImportantForAccessibility field to "No" hides all of the inner html of the webview from Talkback so that is not an option either.
Sidenote that I find interesting: in my experimentation, I also tried setting the WebView's isClickable property to false and yet it was still clickable. So I am wondering if I am possibly focusing on setting properties on the wrong control (or if Android just completely ignores those properties on a WebView control).
Information: I suppose you've seen this dark box appear around a link when you click it on an iPad/iPod/iPhone. If not, click a link, and you'll see it appear and disappear when the new page has loaded.
I have a webapp that is going to be used on all platforms. I use p-tags as links because I don't want a lot of the a-tag default functionality and appearance, and the links are executed via JavaScript.
The problem is that even though I use p-tags, the iPad displays this annoying dark box around the link when you click on it. The dark box is useful to tell the user that they actually managed to click the link while the next page loads, but this webapp loads stuff from localStorage, so there is no need to have this box that clutters the GUI...
How can this box be removed?
Your reason to use paragraph (p-tags) for links is completely a mystery to me. You can control styling via CSS, no matter what tag it is. P-tags are for paragraphs, A-tags are for links. That's the most basic thing in HTML semantics I can think of.
The box you are refering to is "-webkit-tap-highlight-color"
See http://css-infos.net/property/-webkit-tap-highlight-color
I been trying to debug a problem with some odd behaviour inside a UIWebView. My app uses a UIWebView to display a custom form to collect certain information. When the form is first loaded, filled and submitted, everything behaves as it should. After the first submit, when the form is reloaded, the keypad will not display (but the content scrolls as though it is).
The only solution I have come across is here, but this does not seem like the solution to my problem since that line is already in my app delegate.
Is this a known issue? I don't even know where to start looking to debug this issues.
After much searching SO and Apple forums, it was the view hierarchy that was getting rearranged. In my particular case, a progress indicator was being added as new window (by a coworker, so I can blame someone else for this). The trick was not set this new as the key window and only manipulate the the hidden properties
This is just a quick fix because it was only one line of code that was causing this major problem.
When to use HyperLink and when to use Anchor?
When using HyperLink how to handle clicks?
com.google.gwt.user.client.ui.Hyperlink.addClickHandler(ClickHandler) is deprecated
com.google.gwt.user.client.ui.Hyperlink.addClickListener(ClickListener) is deprecated as well.
Doc suggests to use Anchor#addClickHandler, but how to use Anchor#addClickHandler when using HyperLink
Does it mean that if I need to handle click I should always use Anchor and never use HyperLink?
Great question, because it is so simple, and yet opens up what might be a whole new area for a lot of GWT programmers. I've up-voted the question just because it can be a great lead-in for people exploring what GWT can do.
Anchor is a widget for storing and displaying a hyperlink -- essentially the <a> tag. Really not much more exciting than that. If you want your page to link to some external site, use anchor.
Links are also used for internal navigation. Let's say I have a GWT app that requires the user to login, so on my first panel I put a login button. When the user clicks it, I would display a new panel with widgets to collect the user's information, code to validate it, and then if validated successfully, reconstruct that first panel the user was on.
Buttons are nice, but this is a browser, and I want my user's experience to be more like a web page, not a desktop app, so I want to use links instead of buttons. Hyperlink does that. The documentation for hyperlink describes it well:
A widget that serves as an "internal" hyperlink. That is, it is a link
to another state of the running application. When clicked, it will
create a new history frame using History.newItem(java.lang.String),
but without reloading the page.
Being a true hyperlink, it is also possible for the user to
"right-click, open link in new window", which will cause the
application to be loaded in a new window at the state specified by the
hyperlink.
That second sentence should help clear it up. The hyperlink is not changing the page in a URL sense (the way anchor does), though the URL will reflect the state of the program by displaying the "token" associated with the hyperlink appended to the base URL after a slash. You define the token. It would be something descriptive like "login" or "help" or "about". But this isn't a new page. There is no additional HTML file you've had to construct to display a help page, for example. It is the state of the current GWT app that is changing. Even if you "open in a new window" you are just running the same app in a particular state.
It looks like a link, but it is really a widget that manipulates the history frame, which in turn allows you to move the state of your GWT application. You don't write a click handler for the hyperlink widget, but a value change handler for the history stack. When you see that the "help" token has been put on the history stack, your handler will execute GWT code to attach to the RootPanel a FlowPanel with embedded HTML text with your help information. This is perceived by the user as a "new page", which is what he expects when he clicks on a hyperlink. The URL will be something.html/help. Now pretend he returns to this URL via the back button, not your hyperlink. No problem. You don't care about the hyperlink click. You only care that, somehow, the history stack changes. Your value change handler fires again, and does the same thing as before to display the help panel. The user still enjoys the experience of navigating through web pages, even though you and I know that there is only one web page and that you are attaching and detaching panels to the RootPanel (or whatever scheme you are using to display your GWT panels).
And this leads to a bonus topic.
This bonus is a bit more complicated, but ironically, it could help better understand hyperlinks. I say more complicated, but really, it helps solidify this notion that a GWT application is made up of a series of states, and that the web page on the screen is just the user's perception of those state changes. And that is Activities and Places. Activities and Places abstracts away this history frame manipulation, handling it in the background once you've set up a mapper with a GWT-provided class designed for this purpose, allowing you to break down your app into a series of activities, and as the user interacts through these activities he is put into different places, and each place has a view. Moreover, the user can move from place to place using browser controls like the address bar, bookmarks, history, and the backward/forward buttons, giving the user a real web-like experience. If you really want to get a grip on the conceptual difference between hyperlinks and anchors, you should try to learn this GWT topic. It can really make you change the way you see your apps, and for the better.
Hyperlink (or InlineHyperlink) is basically no more than a kind of Anchor with a ClickHandler that calls History.newItem and preventDefault() the event (so that the link is not actually followed).
Actually, Hyperlink won't do that if it thinks (and yes, it's only a guess) you right-clicked or middle-clicked (or ctrl-clicked) on the link (depending on the browser), to open the link in a new window or tab.
If you need any other behavior, then don't use Hyperlink and use Anchor instead. And if you want to add some behavior to an Hyperlink, then use an Anchor and mimic what the Hyperlink does. And you can reuse the HyperlinkImpl to have the right-click/ctrl-click handling (see links below).
But actually, if you need something that looks like a link and do something on click, but does not have a "target URL" (i.e. it shouldn't be right-clicked/ctrl-clicked to open in a new window/tab, or it wouldn't mean anything to do so), then do not use either an ANchor or Hyperlink, use a Label of whatever instead, and make it look like a link (but well, maybe you should use a Button and have it look like a button then; Google used to have link-alike buttons –such as the "refresh" link/button in GMail– and changed them to look like buttons when they really aren't links).
See also https://groups.google.com/d/msg/google-web-toolkit/P7vwRztO6bA/wTshqYs6NM0J and https://groups.google.com/d/msg/google-web-toolkit/CzOvgVsOfTo/IBNaG631-2QJ
I am trying to find the most usable/accessible way to implement a simple form dropdown list which will sort a list of products by pice and alphabetical order.
In your opinion is the dropdown more usable when there is a button that governs its submission or when it automatically submits onchange of the dropdown?
The research I have read is both for and against such methods and there is a variery of implementations on the web so interest to hear the thoughts of the community.
Thanks in advance
As a blind computer user either method works fine. I find that having a button to click is slightly easier for me then the onchange event firing. I wouldn't say it's a big enough difference to take into account though assuming the majority of your users will not be disabled. If your targeting specifically blind users I would not use the onchange event.
So long as you do not change focus or navigate to another page when the selection changes, either approach should work. The classic example of a problem dropdown is where it contains a list of other pages on the site, and navigates as soon as the selection changes. This prevents a keyboard user from using the list; they can't browse it, and can't navigate to any pages beyond the first selection, since it's impossible to navigate past those. So in cases where focus changes or the page navigates as a consequence, having a separate action (eg. Go button, or handling enter) to cause the navigation to take place is essential. This is likely where the advice you've read is coming from.
In this case, however, it sounds as though you are just updating content elsewhere on the page, and not changing focus or doing navigation. Simply resorting existing content should be fine.
Depends on your users and their respective expectations and the context in which it's presented.
As a blanket, general statement, you should have the drop down accompanied by very obvious submission button. That is the safer approach.
If you are refreshing page data or if the focus moves away after the dropdown option is selected, you should use a button to be accessible. If you fire the event on change, blind or keyboard-only users will not be able to use the dropdown menu at all if they are on windows with ie and chrome (so added together, a majority of the people on windows). As soon as they use the arrows to scroll down and make a selection, the first option they hit will be selected and the page data will refresh or the focus will move, making it impossible for them to navigate or select the second option, third option, etc. Below is a thorough explanation with examples so you can see what I mean.
Designers definitely don't like the buttons, but if you are blind and on chrome/ie, it is impossible to use a lot of dropdowns without it. I'm guessing Jared uses firefox or a mac.
http://pauljadam.com/blog/javascript/onchange-event-on-a-select-inputjump-menu-accessibility-problems/