Closed Bug 539455 Opened 15 years ago Closed 15 years ago

[shared module] Request for location bar helper class (part of ToolbarAPI)

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: tracy, Assigned: whimboo)

Details

(Whiteboard: [mozmill-doc-complete])

Attachments

(2 files, 1 obsolete file)

Listed below are items I think will be used most often Elements within the awesomebar field itself: - URL - Favicon (can the actual favicon be determined? not just that one is present) - Star (empty and full(bookmarked)) - RSS feed icon (present or not) Elements in autocomplete: - Matched (sub)string in a list item (matches for a single occurrence and for every occurrence) : -- Title -- URL -- Favicon -- Star - list item count -- # of visible items -- Total # of items others I haven't thought of?: - -
Lets see which parts are possible. It's my next working item.
Summary: Create an API for ease of access to various elements of the awesomebar → [shared module] Needs for a LocationbarAPI (easier access to elements and common functions)
I will stick a location bar class into the new ToolbarAPI.
Summary: [shared module] Needs for a LocationbarAPI (easier access to elements and common functions) → [shared module] Request for location bar helper class (part of ToolbarAPI)
Attached patch Patch v1 (obsolete) — Splinter Review
This patch implements two helper classes. One for the locationbar and the other for the auto-complete popup. Existing tests have been updated too.
Attachment #422215 - Flags: review?(adesai)
Now with the API added too.
Attachment #422215 - Attachment is obsolete: true
Attachment #422216 - Flags: review?(adesai)
Attachment #422215 - Flags: review?(adesai)
Comment on attachment 422216 [details] [diff] [review] Patch v1.1 [checked-in] passes on osx and winxp. No problems with syntax.
Attachment #422216 - Flags: review?(adesai) → review+
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
A couple concerns: 1) Is assertTextUnderlined flexible enough to check title or URL individually? It looks to me like a combined check for both. There will be cases when both will not necessarily match a given test string. 2) for getElement, do the checks for the Star include whether it's empty (not bookmarked) or full (bookmarked)? also, can this verify actual favicon. Not just that one is present? 3) Is there some place that can do checks for actual favicon or star within popup list items. Again for the favicon, check match to expected site favicon, not just that some favicon is present. everything else looks good at first glance. This will be very helpful.
(In reply to comment #7) > 1) Is assertTextUnderlined flexible enough to check title or URL individually? > It looks to me like a combined check for both. There will be cases when both > will not necessarily match a given test string. What do you mean? URL and the title will always have the same characters underlined. There is really no difference. > 2) for getElement, do the checks for the Star include whether it's empty (not > bookmarked) or full (bookmarked)? also, can this verify actual favicon. Not > just that one is present? Retrieve the star via that function. If the page is bookmarked you can get from its property "bookmark". Same for the Favicon. Please check with DOMi to get all the available properties. > 3) Is there some place that can do checks for actual favicon or star within > popup list items. Again for the favicon, check match to expected site favicon, > not just that some favicon is present. Should all be properties of the result object.
(In reply to comment #8) > (In reply to comment #7) > > 1) Is assertTextUnderlined flexible enough to check title or URL individually? > > It looks to me like a combined check for both. There will be cases when both > > will not necessarily match a given test string. > > What do you mean? URL and the title will always have the same characters > underlined. There is really no difference. No, our advanced match test case calls for checks of things like http:// and .org Those usually won't be matched in the page title. Conversely, a string in the page title isn't necessarily going to be in the url. for example: "Mail" is in this page title but not in the url. https://login.yahoo.com/config/login_verify2?&.src=ym > Should all be properties of the result object. Ok, I'll need some guidance on how to dig that stuff with these helpers.
Alright, I missed that. Let's reopen for an immediately follow-up fix. Will be ready today...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [mozmill-doc-needed]
Attachment #422216 - Attachment description: Patch v1.1 → Patch v1.1 [checked-in]
Separated the checks for underlined url and title. Now you can specify the type via a parameter.
Attachment #422592 - Flags: review?(adesai)
Attachment #422592 - Flags: review?(adesai) → review+
Follow-up landes as: http://hg.mozilla.org/qa/mozmill-tests/rev/0b744987e7e8 http://hg.mozilla.org/qa/mozmill-tests/rev/6be98c96fcd6 Other needs or changes we should discuss in the appropriate bugs.
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
Thanks Henrik. These helpers will be, well, helpful. :-) Expect questions and test cases from me to start trickling in next week.
Status: RESOLVED → VERIFIED
Whiteboard: [mozmill-doc-needed] → [mozmill-doc-complete]
Mass move of Mozmill Test related project bugs to newly created components. You can filter out those emails by using "Mozmill-Tests-to-MozillaQA" as criteria.
Component: Mozmill → Mozmill Tests
Product: Testing → Mozilla QA
QA Contact: mozmill → mozmill-tests
Version: Trunk → unspecified
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: