| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
| |
the Browser is in the background. So we won't continue to
burn the battery if there is some mis-behaved JavaScript
running.
Fix http://b/issue?id=2147840
|
| |
|
| |
Fix http://b/issue?id=2151115
|
| |
|
|
|
|
| |
Remove the FakeWebView and all the picture stuff from the picker data. Use the
favicon in a layout similar to history and bookmarks. Add tab_view_add_tab.xml
to have a simpler layout for the "new tab" item in the list.
|
| |
|
|
|
|
|
| |
When the container is removed from the content view, its child views do not lose
focus. Removing the WebView from the container as well will trigger a focus
change from the WebView. Move the attach/remove logic to TabControl since it
knows all about the containers.
|
| |
|
|
|
|
|
|
| |
In switchToTab, I think it is wrong code where it calls removeTabFromContentView(tab).
In openTabAndShow, we should really attach after we the tab to the current.
Fix http://b/issue?id=2067930
|
| |
|
|
|
| |
This prevents a NPE when the current tab is null. This is very rare but can
still possibly happen.
|
| |
|
|
|
|
|
| |
In addition the sliding title bar, I have now removed the TabPicker.
Now, when changing to a new tab, we just go straight there. Also
put back in Add bookmark in the top level menu. And fix the bug
where switching tabs was always bringing up the bookmarks.
|
| | |
|
| |
|
|
|
| |
bug found by findbugs
http://b/issue?id=1856695
|
| |
|
|
|
|
|
|
| |
Note that the appearance of the prompt has not yet been finalized.
Also the interaction of the prompt with the animation used to move to and from
the tab picker is not fixed. This may become unecessary if the tab selection UI
is redisgned.
|
| |
|
|
|
|
|
|
| |
current tab around so that hit Back won't cause reload the page.
This should address the complain of reloading while using Google Reader.
Remove our own checkMemory() as the system now provides onLowMemory().
|
| |
|
|
| |
enabled debug in the browser (been to about:debug) and there are errors on the page. It can be toggled on/off in debug mode in the settings menu.
|
| |
|
|
|
|
|
|
|
|
| |
If there is no matching application tab, try to find a regular tab (created in
the browser) with a matching url. This avoids opening a new tab and loading a
new page for a page that has already been loaded.
TODO: There is a ton of duplicate code around animations to/from the tab
overview. It is a massive amount of cruft and I really want to rewrite it all in
a separate change.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When we are in the tab picker and a new tab is created from bookmarks/history,
show the new tab in the picker and then animate to it. Only do this for the
"open tabs in background" setting since openTab() will show the tab if that
setting is false.
We animate to the new tab because we currently don't have a way to show the new
tab in the tab picker with updated picker data (title and url in particular).
So instead of showing a blank tab, animate to the tab. Once the animations have
been redesigned and the code refactored, this will hopefully get better.
|
| |\
| |
| |
| |
| |
| |
| | |
Merge commit '73972695c844b25370ad738bb76e8eb2e9cd81e6'
* commit '73972695c844b25370ad738bb76e8eb2e9cd81e6':
Fix 2 NPEs in the Browser.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The first was from freeMemory getting a tab back that had already been freed.
This is a really hard case to reproduce but it appears that it can happen. So
just check for a null mMainView before trying to free the tab.
The second was a null mTabOverview during the onAnimationStart method when
animating to the tab overview. I think this is caused by message delays not
being accurate enough to ensure the overview has been created. A check for null
fixes the problem for now but I am working on a better solution to ensure
animation message order.
|
| | | |
|
| | |
| |
| |
| |
| | |
- pause when a view is in a non-current tab
- pause the current view when the activity itself is paused
|
| |\|
| |
| |
| |
| |
| |
| | |
Merge commit '20abe047a9f424a916e1b2a5d8b614b9b466e924'
* commit '20abe047a9f424a916e1b2a5d8b614b9b466e924':
Check for null before accessing mPickerData.
|
| | |
| |
| |
| |
| |
| | |
It could be null when switching to a parent tab since the parent tab will be
restored before showing the tab picker. This clears mPickerData before building
the tab picker.
|
| |\|
| |
| |
| |
| |
| |
| | |
Merge commit '761b3b5a23c06b64b9ecb99953665d2059e3b145'
* commit '761b3b5a23c06b64b9ecb99953665d2059e3b145':
Show the saved picture for freed tabs.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Create a small class containing the data needed to display the saved or current
picture. For freed tabs, inflate the picture and use the saved state from
mSavedState. Reorganize populatePickerData to use the current top window or the
saved state depending on if the tab has been freed.
There was another bug where onNewPicture would update the wrong FakeWebView due
to ListViews reusing the same view. Have the tab manage the new picture and
invalidate the FakeWebView. When reusing the view, clear out the tab's
FakeWebView field.
Wipe all the picker data at the same time the ImageGrid and ImageAdapter are
cleared.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| | |
The semantics of Config.DEBUG will be changing soon, and all other
Config.* fields will become deprecated/hidden.
BUG=1780938
|
| |/
|
|
|
|
| |
The tab will most likely not be null but the top window could easily be null if
the tab has been freed due to low memory. Update getTabIndex to return -1 if the
tab is null.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
