Closed Bug 941176 Opened 12 years ago Closed 11 years ago

[User Story] [Meta] Browser Chrome: View title

Categories

(Firefox OS Graveyard :: Gaia::System::Browser Chrome, defect)

x86
macOS
defect
Not set
normal

Tracking

(feature-b2g:2.1)

RESOLVED FIXED
2.1 S3 (29aug)
feature-b2g 2.1

People

(Reporter: pdol, Assigned: vingtetun)

References

Details

(Keywords: verifyme, Whiteboard: [ucid:System126, 1.4:P2, ft:systemsfe], system-browser, [p=2])

Attachments

(1 file)

46 bytes, text/x-github-pull-request
daleharvey
: review+
Details | Review
User Story: As a user I want to view the title of the web page I'm currently on so that I can see the title of the website I am currently viewing. Acceptance Criteria: Functionality should match existing Browser functionality unless described otherwise in UX spec.
Component: Gaia::System → Gaia::System::Browser
No longer blocks: browser-chrome-mvp
Assignee: nobody → kgrandon
Status: NEW → ASSIGNED
Attached file Github pull request
Dale - just marking you as reviewer so you are aware. We should probably land your places datastore work first, or this will cause conflicts - and I'm sure I've given you plenty of those already :) Feel free to review now, and we can land it at a later date. Tests are coming.
Attachment #8350674 - Flags: review?(dale)
Comment on attachment 8350674 [details] [review] Github pull request Starting to touch some system components, so alive should probably review this one as well :)
Attachment #8350674 - Flags: review?(alive)
Comment on attachment 8350674 [details] [review] Github pull request I'd like to publish the events from appWindow instead of appChrome. To do this you need to add new events in AppWindow.REGISTERED_EVENTS and implement _handle_ + EVENT_NAME handler in AppWindow.prototype. AppWindow.prototype.publish is your good friend to publish events. Apology for not documenting these principles well.
Attachment #8350674 - Flags: review?(alive)
Comment on attachment 8350674 [details] [review] Github pull request Hi Alive, Thanks for the awesome/quick review. I added one commit for some tests, and one commit for some adjustments. (Will squash before landing). The new adjustments make sense and feel clean to me, so great ideas! Please let me know if you find anything else.
Attachment #8350674 - Flags: review?(alive)
Comment on attachment 8350674 [details] [review] Github pull request Gonna clear r, theres a bug where navigating from web content to app contant (in particular e.me results) the title of the web content persists, I think its a pretty big bug that should be simple to fix, so think it would be good to fix before merging It also looks strange on the lockscreen, however I think thats a more complex fix that will require UI follow up, so happy to merge before fixing that. The rest looks really great, the tests on travis look unrelated so spun a new run
Attachment #8350674 - Flags: review?(dale)
Comment on attachment 8350674 [details] [review] Github pull request Hi Dale, I've pushed a fix (including test), which does not allow inactive app windows to update the title. Before, the titlechange may have been updating the title after you close the window. I think this may have been what you are seeing. To clarify, the following cases work for me: 1 - Open rocketbar, type url, press enter. Title appears. 2 - Press home, launch app 3 - Title disappears 1 - Open rocketbar, type url, press enter. Title appears. 2 - Open rocketbar again, and tap everything.me result 3 - Title updates with new E.me page title.
Attachment #8350674 - Flags: review?(dale)
Comment on attachment 8350674 [details] [review] Github pull request Yup thats great, apologies for not being clearer with the STR New version looking awesome
Attachment #8350674 - Flags: review?(dale) → review+
Comment on attachment 8350674 [details] [review] Github pull request Alive - I've updated the pull request based on your feedback, and if you have any additional concerns, we can submit follow-up patches.
Attachment #8350674 - Flags: review?(alive)
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
This is a good start but let's keep the user story open until we're ready for acceptance from Product/QA, we're not quite done here yet as it doesn't meet the UX spec. Stealing.
Assignee: kgrandon → bfrancis
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: --- → 1.3 C2/1.4 S2(17jan)
Depends on: 958582
Let's make this a meta bug.
Assignee: bfrancis → nobody
Summary: [User Story] Browser Chrome: View title → [User Story] [Meta] Browser Chrome: View title
Blocks: 959353
Depends on: 960250
I don't see a lot here, and I *think* that most work is now going to be a part of bug 959694. Closing so our focus for user testing makes sense.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
No longer depends on: 960250
Depends on: 961724
Depends on: 960250
We're still not done here. Please leave this bug open until we're ready for acceptance by Product/UX/QA. Unblocking 959353 as the patch on the Rocketbar branch fixes that requirement.
No longer blocks: 959353
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Estimating as 2 points. This is assuming the necessary platform pieces are in place. We need some limited logic here to decide when to display the content of the <title> element, the app name, or the application-name meta tag.
Whiteboard: [ucid:System126, 1.4:P2, ft:systems-fe], system-browser → [ucid:System126, 1.4:P2, ft:systems-fe], system-browser, [p=2]
Depends on: 967065
No longer blocks: rocketbar-search-mvp
Flags: in-moztrap?(nhirata.bugzilla)
No longer blocks: 1.4-systems-fe
blocking-b2g: --- → backlog
feature-b2g: --- → 2.1
Whiteboard: [ucid:System126, 1.4:P2, ft:systems-fe], system-browser, [p=2] → [ucid:System126, 1.4:P2, ft:systemsfe], system-browser, [p=2]
Candice, can you help to assign updated target milestone for this 2.1 bug? Thanks.
Flags: needinfo?(cserran)
Depends on: 1042793
Assignee: nobody → bfrancis
blocking-b2g: backlog → ---
Flags: needinfo?(cserran)
Target Milestone: 1.3 C2/1.4 S2(17jan) → 2.1 S1 (1aug)
Depends on: 1043932
Looks like Vivien is working on this in bug 1039519, not much point in it being assigned to me. https://bugzilla.mozilla.org/show_bug.cgi?id=1039519#c22
Assignee: bfrancis → 21
Target Milestone: 2.1 S1 (1aug) → 2.1 S2 (15aug)
Target Milestone: 2.1 S2 (15aug) → 2.1 S3 (29aug)
Ready for acceptance testing :)
Status: REOPENED → RESOLVED
Closed: 12 years ago11 years ago
Keywords: verifyme
Resolution: --- → FIXED
Flags: in-moztrap?(nhirata.bugzilla) → in-moztrap?(mozillamarcia.knous)
Flags: in-moztrap?(mozillamarcia.knous)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: