Closed Bug 698223 Opened 12 years ago Closed 12 years ago

Display URI in AwesomeBar and results if no title is present

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: aaronmt, Assigned: lucasr)

Details

Attachments

(4 files, 2 obsolete files)

Attached image Nightly (10/29)
See screenshot

I/Gecko   ( 1613): Got message: onStateChange
I/GeckoApp( 1613): State - 983041
I/GeckoApp( 1613): Got a document start
I/Gecko   ( 1613): Got message: onLocationChange
I/GeckoApp( 1613): URI - http://mw.weather.com/
I/Tab     ( 1613): Updated url: http://mw.weather.com/ for tab with id: 2
I/Gecko   ( 1613): Got message: onStateChange
I/GeckoApp( 1613): State - 196612
I/Gecko   ( 1613): Got message: DOMTitleChanged
I/GeckoApp( 1613): title - 
I/Gecko   ( 1613): Got message: DOMContentLoaded
I/GeckoApp( 1613): URI - http://mw.weather.com/, title - 

--
Mozilla/5.0 (Android; Linux armv7l; rv:10.0a1) Gecko/20111029 Firefox/10.0a1 Fennec/10.0a1
Samsung Nexus S (Android 2.3.6)
Assignee: nobody → lucasr.at.mozilla
Attachment #570748 - Flags: review?(mark.finkle)
Attachment #570749 - Flags: review?(mark.finkle)
Comment on attachment 570748 [details] [diff] [review]
(1/2) Use URL as title on tabs when title is empty

This gives a wrong notation in tab management. The title, if "", better be the same.
In the second patch, it can be more like, tab.getTitleString() which can return title or url (if title is not present).
Having url as title in Tab.java is not a good approach to me.
Attachment #570748 - Flags: review?(mark.finkle) → review+
Attachment #570749 - Flags: review?(mark.finkle) → review+
(In reply to Sriram Ramasubramanian [:sriram] from comment #3)
> Comment on attachment 570748 [details] [diff] [review] [diff] [details] [review]
> (1/2) Use URL as title on tabs when title is empty
> 
> This gives a wrong notation in tab management. The title, if "", better be
> the same.
> In the second patch, it can be more like, tab.getTitleString() which can
> return title or url (if title is not present).
> Having url as title in Tab.java is not a good approach to me.

What use cases do you have in mind that this change would break? Anyway, I can add a method called getTitleForDisplay (better than "getTitleString" I think) method and keep getTitle as is.
Attachment #570748 - Flags: review+ → review?
Rethinkning the mTitle = mURL change
Attachment #570748 - Attachment is obsolete: true
Attachment #570748 - Flags: review?
Attachment #570807 - Flags: review?(mark.finkle)
Attachment #570808 - Flags: review?(mark.finkle)
Attachment #570749 - Attachment is obsolete: true
Attachment #570809 - Flags: review?(mark.finkle)
Attachment #570807 - Flags: review?(mark.finkle) → review+
Attachment #570808 - Flags: review?(mark.finkle) → review+
Attachment #570809 - Flags: review?(mark.finkle) → review+
Lucas, do your patches address history items? For example; on visiting the site in comment #0 (e.g, http://mw.weather.com), the site URI is now displayed in the url bar as expected, but upon visiting the history tab and seeing its entry, the site title is missing from the entry  -- would it make sense to repeat the site URI for the listed title?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Aaron Train [:aaronmt] from comment #10)
> Lucas, do your patches address history items? For example; on visiting the
> site in comment #0 (e.g, http://mw.weather.com), the site URI is now
> displayed in the url bar as expected, but upon visiting the history tab and
> seeing its entry, the site title is missing from the entry  -- would it make
> sense to repeat the site URI for the listed title?

This sounds like bug 697803 which I fixed yesterday.
Follow-up via bug above.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
20111101040211
http://hg.mozilla.org/projects/birch/rev/7203d86d5868
Motorola Droid Pro (Android 2.3)
Status: RESOLVED → VERIFIED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.